GP migration assessment: what it should produce

Microsoft has dated the end of Dynamics GP. Product enhancements, regulatory (tax) updates and technical support stop on 31 December 2029, and security updates, “if needed”, on 30 April 2031. New customers could license GP subscriptions only until 1 April 2026. Microsoft’s July 2026 migration post is as specific about where a move starts: “The first step is to work with a Microsoft partner to assess the current environment, including customizations, integrations, data, reporting needs, security requirements, and business processes.”

A GP migration assessment should therefore end in deliverables that later decisions depend on, not a readiness score. There are six:

1. The dates that apply to this estate’s GP version.
2. A pass or fail against the cloud migration tool’s prerequisites, with every fail turned into a dated work item.
3. What the tool will carry, what it will not, and the settings it forces you to choose.
4. An inventory of customisations, add-ons, integrations and reports, with a decision on every line.
5. A history decision for each company, sized against Business Central’s storage.
6. A priced, dated plan.

What happens once the migration is running, including the three steps that cannot be undone, is covered in our article on GP to Business Central migration. This one covers the work that comes before it.

The deadline, in Microsoft’s dates

The date has moved once. Microsoft’s end of support announcement was updated on 15 January 2025 (“Dynamics GP product support and updates will now end on December 31, 2029”), replacing 30 September 2029. The security date did not move.

So Dynamics GP end of support is three dates, not one, and the two 2031 rows are different things that share a day. The second is what Microsoft’s July 2026 post calls “product availability ending”. The first is the last patch. And before any of them arrives, Microsoft’s GP documentation already warns that “the level of support we can offer may no longer match the standards you’ve come to expect, as resources and updates for Dynamics GP become increasingly limited.”

Which clock applies to this estate

Those dates are for GP 18.x, which Microsoft’s lifecycle page says “is governed by the Modern Lifecycle Policy”. Under that policy, customers “stay current by taking at least one of the three all-inclusive Dynamics GP updates, typically released in June, October, and December each year.” Older versions are on fixed dates:

GP 2018 has a twist: “Installing any compatible Dynamics GP tax release or hotfix on Dynamics GP 2018 or Dynamics GP 2018 R2 will bring you to version 18.5 or later, which enacts the Modern Lifecycle Policy.” So the first deliverable records the installed build and the last update taken for every GP instance, not the product name on the licence.

Add one platform date. SQL Server 2016, the oldest SQL Server the migration tool accepts as a GP source, left extended support on 14 July 2026. In our experience that is where most GP estates trip first: the GP version is supported, but the SQL Server underneath it is close to or past its own end of support. Treat it as a dated work item at the front of the plan, not something to discover during the migration.

Can you use Microsoft’s cloud migration tool?

For a GP cloud migration, Microsoft’s migration overview documents one built-in route: “You can use the built-in migration tools to migrate data to Business Central online from Dynamics GP 2015 and later versions.” Whether this estate can use the Business Central cloud migration tool is a pass or fail against the GP prerequisites page. It is stricter than Microsoft’s general migration page, asking for SQL Server 2016 SP1 rather than SQL Server 2016, so assess against the GP page.

• GP version. GP 2015 or later. Below that, “upgrade to the latest supported version” first.
• SQL Server. “SQL Server 2016 SP1 or later”, compatibility level 130 or higher, TCP/IP enabled, SQL Server authentication, and a login with the sysadmin role on the server and db_owner on the database.
• SQL Server 2014 or earlier. Upgrade the production database first, or migrate from a backup restored to SQL Server 2022 or later developer edition, “as long as you don’t use that SQL Server for other workloads.”
• Backups. Full backups only: “Differential or partial backups aren’t supported as they don’t include Change Tracking data required for replication runs” (GP planning page).
• Market. The Cloud Migration Setup assisted setup guide supports GP only in the United States, Canada, the United Kingdom and Australia. Anywhere else, the route has to be designed, not assumed.
• Approval. A partner running setup as a delegated administrator needs approval from a licensed user with an Essentials or Premium licence and SUPER permissions (setup page). The plan names that person.

A fail is not a reason to stop. It is a dated work item at the front of the plan, because a Dynamics GP migration through the tool cannot start until it closes.

What the tool carries, and what it makes you decide

Microsoft’s page on GP data migrated to Business Central online matters more to a GP migration assessment than the overview does, because nearly every item on it carries a choice. The company configuration page names one setting that cannot be skipped and one it calls best practice: “you’re required to make changes if there’s more than one segment in Dynamics GP because you must indicate which segment to use the global dimensions. And as best practice, you should specify how many years back to migrate data, otherwise the tool migrates all years.”

The defaults are decisions too. All modules are selected, “no inactive records or discontinued items are migrated”, and migrated transactions are posted automatically in batches. The assessment records which way each one goes, per company, and why.

What is not on the list

Several of the additional GP features and components do not appear on Microsoft’s list of GP data migrated: Analytical Accounting, Fixed Asset Management, Manufacturing, Project Accounting, Grant Management and, in the United States, Payroll Suite and Human Resources. Each one in use needs a named route and an owner before anyone estimates the migration.

Acceptance needs the same treatment. Microsoft’s validation step “compares source data from Dynamics GP with migrated data in Business Central to identify discrepancies”, and it tests eight entities: G/L accounts, statistical accounts, bank accounts, customers, items, purchase orders, vendors and Vendor 1099 information. Anything else, the Historical Snapshot for one, needs acceptance criteria written in the assessment.

The customisation and add-on inventory

Microsoft’s July 2026 post puts this early: preparing the environment is where you “determine how customizations will be handled”. The mechanism shows why. “Tables fail to migrate if they can’t be found, or if the schema doesn’t match between the cloud and the on-premises tables” (GP migration overview). Tables added by add-ons and customisations are not on Microsoft’s list, and table mapping into Business Central table extensions is closed to GP: “Dynamics GP and SL don’t support table extensions.” On the other side, Business Central is customised through extensions written in AL: “Extensions are a programming model where you define functionality as an addition to existing objects.”

So every GP customisation needs a decision. Build the inventory from what GP itself records, not from memory:

• The registered modules list. GP’s customisation and integration tools are licensed as modules. One naming trap, from Microsoft’s licensing note: Integration Manager appears there as Integration Site Enabler.
• Dexterity customisations. Dexterity is GP’s development environment for customisations (Dexterity releases), so anything built in it is code that needs a decision.
• Modifier with Visual Basic for Applications. Customisations built with it depend on a licence the same note names: “To use the customizations, you must have purchased at least a Customization Site License.”
• Third-party add-ons. Product and version, what it stores in its own tables, who uses it, and whether a Business Central equivalent exists.

The register has one line per item: what it is, who uses it, what data it holds, and its disposition, which is a standard Business Central feature, an app, an AL extension, or retirement.

Two Microsoft constraints turn the register into dates. Replacement apps go in before replication, because afterwards the GP planning page says: “If you need to install or uninstall extensions or delete companies, disable the cloud migration, make the changes, then enable it again.” And add-on data with nowhere to land can still be kept. In the optional Azure Data Lake copy of the GP database, “any files that haven’t been mapped to a folder reside in” a folder named 3rd Party.

Integrations: eConnect, Integration Manager and web services

Microsoft’s component list describes three components built for integration:

• eConnect: “A document integration tool that enables high volume, high speed programmatic integration to and from applications and the Dynamics GP back office solution.”
• Integration Manager: “Allows you to perform a one-time data conversion from your existing system to Dynamics GP products, or to perform ongoing integrations from other applications.”
• Web Services Runtime: “The runtime engine that adds a Web Services interface to Dynamics GP.”

The same list also names OData Services, so look for that too, and add anything that reads or writes the GP database directly, which no module registration will show. Every one of these interfaces is rebuilt for Business Central online, where “OAuth2 is the only authentication option for SaaS” and “SOAP was superseded by OData V4” (deprecated platform features), and a point-to-point integration can be built as a Connect app, “typically created using standard REST API to interchange data.”

In the ERP integration reviews we run, two findings recur, and neither is specific to GP. Most synchronous interfaces we inherit were built that way by default rather than by decision. And more of the interfaces documented as bidirectional turn out to be one-way in practice than the reverse. Since every GP interface is rebuilt anyway, record what each one actually does, not what it was built to do.

Count the patterns while you are there. In our view, more than two or three distinct integration patterns in active use, without a documented reason for each, is already an operations problem even when nothing is broken. The cost shows up as support burden rather than incidents, which is why it persists for years unfunded.

The integration register records the interface, its GP component or direct database access, the direction actually used, its timing, authentication, owner and rebuild target. Choosing the target pattern is the subject of ERP integration patterns.

Reporting: Management Reporter and what replaces it

The last clear Microsoft statement on Management Reporter we could find is an archived 2016 post: “Management Reporter will continue to be supported through the lifecycle of the ERP versions it ships with.” We found no Microsoft documentation of converting Management Reporter report definitions to Business Central, and they do not appear on Microsoft’s list of GP data migrated. Plan each report as a rebuild unless someone can show otherwise.

Business Central’s financial reporting needs “no involvement of a developer”, but it rests on setup done first: “Map G/L posting accounts to G/L account categories. Design how you use dimensions. Set up G/L budgets.” That ties the report rebuild to the segment decision in the table above, so the two belong in the same meeting. For detail from before cutover, the Historical Snapshot tables “can be used in Power BI reports, Power Apps, or other non-Microsoft reporting tools.”

The report register lists each report with its owner, how often it runs, who reads it, the data it needs (current year, history, which dimensions) and its rebuild target.

Data volume and history

Storage is finite. “Storage capacity is determined as 80 GB + allowances per licensed Essential/Premium user + any storage capacity licenses” (GP planning page), and the allowances are 3 GB per Premium licence, 2 GB per Essential and 1 GB per Device. How that limit behaves across environments, and what to ask about how many years of history a quote includes, are in our article on choosing a Business Central partner.

Microsoft’s migration FAQ recommends keeping “the amount of data to less than 30 GB per migration run”, and says “Delete outdated data in tables that contain log entries and archived records before you start the migration.” It also suggests migrating fewer companies per run, and the GP planning page gives the reason: “the more companies you replicate in a single operation, the longer the migration takes.”

History is set per company. Oldest GL Year sets how far back the general ledger summaries go, and a second field, Oldest Snapshot Year, limits how much the Historical Snapshot carries. What the tool leaves behind can be kept in the optional Azure Data Lake copy, which gives “access to the historical data that isn’t migrated by the migration tool.”

The history decision, per company, records the database size before and after clean-up, the Oldest GL Year, the snapshot modules and Oldest Snapshot Year, whether a data lake copy is kept, and which migration run the company belongs to.

Business Central or Finance and Operations

Microsoft’s migration overview documents GP’s built-in path only to Business Central online. The finance and operations upgrade path it describes is for “customers who currently run Dynamics AX 2012”. Microsoft’s GP announcement calls Business Central “Microsoft’s flagship SMB ERP product”, and its functional overview says it “provides functionality for common business processes in small and medium-sized companies, mainly within wholesale and professional services. However, more complex processes, such as assembly, manufacturing, service, and directed warehouse management are also supported.”

The assessment records the target and the reasons for it. An estate heading for finance and operations has no built-in path in that overview, so it is scoped as a project of its own. Where the choice is genuinely open, Business Central vs Finance and Operations sets out what decides it.

The output: a priced, dated plan

Microsoft’s GP migration overview asks for this document by name: “Develop a migration plan that includes a detailed timeline, resource requirements, and migration approach.” It adds the first constraint, “You should plan to run cloud migration between environment updates”, and the GP planning page says “Once you set up cloud migration for an environment, the environment can’t be updated.” The migration window is fixed against Business Central’s update calendar, not chosen freely. The other fixed points come from the registers:

• Prerequisite fixes first, each with its own date.
• Replacement apps installed before cloud migration is enabled.
• Company batches, sized to stay under 30 GB a run.
• The downtime point. In Microsoft’s backup-based approach, use of the on-premises environment stops before the final backup, and in the cloud environment “Once you start the data upgrade on an environment, all client connections are terminated” (data upgrade page). Why that step cannot be repeated is covered in the three one-way doors.
• Security, rebuilt. “All permissions must be granted in the Business Central tenant, independent from your on-premises permissions” (migration FAQ). Role design is a workstream with an owner.
• A version freeze. GP stays current on its 18.x updates until cloud migration is set up, and then stops: the GP planning page says “Do not update the on-premises environment and reschedule updates to the cloud environment to a date after the cloud migration is completed.”
• The end date, set against 31 December 2029.

Then each line is priced, so the plan is approved as a whole rather than one surprise at a time.

What our assessment covers

Our Dynamics migration readiness assessment, from $3,500 is “a fixed-scope assessment of your current system and a costed plan to move, before you commit to the migration”: a fixed fee from $3,500, two weeks, with the price shown up front. It covers:

• Current-state review of your existing system (GP, NAV, SL or other)
• Data quality and volume assessment
• Target Dynamics 365 fit and gap analysis
• Migration approach and cutover plan
• Risk and dependency review
• Fixed-fee migration roadmap and quote

Dynamics 365 licences are billed per user per month through Microsoft CSP, and the $3,500 covers the assessment services. The migration itself is scoped from the roadmap and quoted separately: the migration build, data migration and validation, the customisations and integrations rebuild, and go-live with hypercare.

Our position: build the inventory from the running system

In our view a GP migration assessment is only as good as the evidence behind its inventory. A questionnaire captures what a team believes about its estate; reading the running estate captures what is there, and the gap between the two is usually where the risk is sitting. On GP, reading the estate means the registered modules, the customisations installed, the integration jobs scheduled and the size of each company database.

The most expensive mistake in planning a GP move is pricing or scheduling it before the customisation and integration inventory exists.

So test any assessment you are offered, ours included. If it reads like the output of a free questionnaire with a logo on it, it probably is one. Ask which findings came from looking at the GP system, and ask to see the evidence for one of them.

Microsoft’s own migration assessment tool is a different thing. Microsoft says it “detects potential migration issues based on your Dynamics GP system structure”, and the case for running it before any timeline is in our GP to Business Central migration article. A paid assessment has to add the rest: dates, registers, decisions and a price.

Where to start

1. Run Microsoft’s migration assessment tool, described on the GP migration overview, which “provides migration options based on your needs”.
2. Record the GP build and the last update applied for every instance.
3. Record the SQL Server version, service pack, compatibility level and authentication mode.
4. Export the registered modules list, and list every Dexterity and Modifier with VBA customisation and every third-party add-on.
5. List every integration and Integration Manager job, with the direction it actually runs.
6. List the Management Reporter reports in use, each with an owner.
7. Size each company database, and decide how far back its history needs to go.

Veratas delivers Dynamics migrations onto Business Central, with a fixed-fee readiness assessment before you commit to one. If you are on GP and your plan does not yet have dates and prices on it, talk to our team.

Frequently asked questions

When does Dynamics GP support end? Microsoft ends product enhancements, regulatory (tax) updates and technical support for Dynamics GP on 31 December 2029, and security updates, if needed, on 30 April 2031. Those dates apply to GP 18.x on the Modern Lifecycle Policy. Older versions have their own fixed dates, and extended support for GP 2018 ends on 11 January 2028.

Can new customers still license Dynamics GP subscriptions? No. Microsoft’s final day for new customers to license Dynamics GP subscriptions was 1 April 2026. For existing customers, 30 April 2031 is the date Service Plan coverage ends, SPA/DPL subscriptions can no longer be renewed and no more perpetual users can be added.

What should a GP migration assessment produce? Six things: the lifecycle dates that apply to your GP version; a pass or fail against the cloud migration tool’s prerequisites; a record of what the tool carries and the settings it forces; an inventory of customisations, add-ons, integrations and reports with a decision on each; a history decision for each company; and a priced, dated plan.

Does Microsoft’s cloud migration tool move customisations, add-ons or Management Reporter reports? Not as far as Microsoft documents. Its list of GP data migrated covers setup, master data, transactional data, classes, Vendor 1099 and historical data, and none of those three appears on it. Tables fail to migrate if they cannot be found or their schema does not match, and GP sources cannot map fields into Business Central table extensions.

How much GP history should we migrate? It is a decision for each company, and the assessment should make it explicitly. Microsoft advises setting how many years back to migrate, through the Oldest GL Year and Oldest Snapshot Year fields, because otherwise the tool migrates all years. It also recommends keeping each migration run under 30 GB, and history left behind can be kept in an optional Azure Data Lake copy of the GP database.

Gaurav Aggarwal

Cloud and enterprise architect with 17 years of experience across data platforms, integration and application development. Focus areas include Azure architecture, cloud-native application design, and ERP to data platform integration.