Dynamics GP to Business Central Migration Guide: Timeline, What Moves and Support Dates

Project length depends on customization, connected systems and the amount of history you bring across. The timeline tiers below give a starting point for planning.

Microsoft's final Dynamics GP product support and updates deadline is December 31, 2029, but your installed version can have an earlier lifecycle deadline. Plan from the deadline for your version, update level and infrastructure. Below is how the work breaks down, what moves and what does not, and what to prepare.

How long does a GP to Business Central migration take?

It depends on complexity. GP migrations fall into three tiers, and each has its own typical range.

• Focused: a migration with light customization, usually 8 to 12 weeks.
• Typical: most migrations, usually 3 to 6 months, depending on data volume, customization and integrations.
• Heavily customized: a GP environment with deep customization and multiple integrations, usually 6 to 9 months.

These are typical ranges. The real number depends on your GP version, companies, add-ons, customizations, integrations and the amount of history you want to keep.

The phases of a GP to Business Central migration

Microsoft’s own process for moving GP data to Business Central online runs from assessment through data replication, data upgrade, validation and go-live. A real project wraps design, testing and training around that core. This is the sequence we use.

1. Assessment and scoping. We inventory your GP version, companies, modules, third-party add-ons, customizations, reports and integrations, and agree how much history to move. Microsoft’s cloud migration tool requires GP 2015 or later, so an older version needs an extra step first. This phase ends with a written scope.
2. Data preparation. Clean data moves faster. Inactive customers, vendors and items get a decision, bank reconciliations get finished, and cash receipts are deposited before the move because undeposited receipts do not migrate.
3. Design and configuration. We configure Business Central, map your chart of accounts, set up posting groups and dimensions, replace add-ons with native features or AppSource apps, and rebuild the reports and integrations you still need. In the migration tool, the main account segment becomes the Business Central account number and the other GP segments become dimensions.
4. Trial migrations. We run the migration into a sandbox, check the results, fix what is wrong and run it again. Microsoft allows repeated replication during the replication phase, before the final successful data upgrade. After that upgrade succeeds, do not replicate again from the earlier version: prepare or reset a separate test environment and migration setup for another full rehearsal. Plan on several rounds.
5. Testing and training. Your finance team tests real scenarios against the sandbox, reconciles balances and learns the new screens before anyone depends on them.
6. Cutover and go-live. We schedule the final migration around your quiet periods, run it into production, validate it, switch your users over and retire GP.

GP stays your live system until cutover, so the business keeps running while the project is underway. Once cloud migration is configured, data entry in the Business Central tenant is restricted to data that is not being migrated, so the final cutover window needs to be planned rather than improvised.

What moves and what does not

Master data, open transactions and a configurable amount of history move. Customizations, add-ons and reports do not convert automatically. They get rebuilt or replaced. The details below come from Microsoft’s documentation for migrating GP data to Business Central.

What moves

What does not move, or needs a decision

Source: Migrate Dynamics GP data to Business Central online, Microsoft Learn. Checked October 2026.

The history decision has a large effect on effort. Moving balances plus a historical snapshot is lighter than rebuilding every posted transaction line by line, and the snapshot keeps older detail available for lookups and reporting.

Where GP features land in Business Central

Most GP tools have a Business Central counterpart, but the migration tool does not carry the setup across. Your reports, lists and approvals are rebuilt in the new system. This table shows where each one lands.

What drives the timeline

Four things move a migration between tiers.

• Customization depth. Dexterity or VBA customizations and heavy report writing each need to be understood, then rebuilt or retired.
• Integrations. Every connected system (EDI, e-commerce, payroll, banking, CRM) needs to be repointed and tested.
• Data volume and history. More companies, more years and more historical detail mean more trial runs and more reconciliation.
• Your team’s availability. Testing and sign-off need finance people. Projects slip when the same people are also closing the books.

Add-on count matters too. Many GP bolt-ons for workflow, document management and web access have native equivalents in Business Central, which shortens design work when they can simply be retired. Our guide to migrating to Business Central online covers the wider migration options, and if part of your estate is still on NAV, read why upgrading Dynamics NAV to Business Central matters.

For project costs, a license price calculator and a fixed-price quote, see our Dynamics GP to Business Central migration services.

GP support dates and why they matter

Microsoft announced that Dynamics GP product support and updates end on December 31, 2029, and that security patches end on April 30, 2031. The support date was originally September 30, 2029 and moved to December 31 in an update dated January 15, 2025. Both dates are in Microsoft’s end-of-support announcement for Dynamics GP.

Those are final product retirement dates, not a promise that every installed GP version stays supported until then. Check your installed version, update level and infrastructure first: for example, Microsoft lists extended support ending in July 2026 for GP 2016 and January 2028 for GP 2018. For GP 18.x and later, use Microsoft's current system requirements to confirm the update level and supported infrastructure.

Microsoft has also said the final day for new customers to license GP subscriptions was April 1, 2026. Its GP and SL migration options post points GP customers to Business Central.

Work backward from the lifecycle deadline that applies to your installed version, update level and infrastructure. GP 2016 and GP 2018 have earlier published deadlines, while December 31, 2029 is the final product retirement date. A typical migration is 3 to 6 months, and a heavily customized one can be 6 to 9. Add time for scoping, budget approval and fitting the cutover around your year-end close. Starting early keeps the choice of cutover window in your hands.

A checklist to prepare

1. Confirm your GP version. The cloud migration tool needs GP 2015 or later.
2. List every company, module and third-party add-on you use.
3. List every customization, custom report, SmartList and Management Reporter layout, and mark which ones people still use.
4. List every system that connects to GP, and how it connects.
5. Decide how many years of history you need in the live system and how many only need to be searchable.
6. Clean up inactive customers, vendors and items, finish bank reconciliations and deposit outstanding receipts.
7. Name a finance owner who can test and sign off, and block their time.
8. Pick a cutover window away from your year-end and audit.
9. Count the users who need full licenses and the ones who only need Team Members access.

If you can answer most of these, you have what you need to place your migration in one of the three timeline tiers.

Download this checklist as a PDF to share with your team.