Starting Point
Your Dynamics GP Environment
Your companies, segmented chart of accounts, Dexterity and VBA modifications, ISV add-ons, payroll, and years of transaction history.
Microsoft has set a final date for Dynamics GP. But the deadline that actually affects your finance team is earlier than 2029, and it depends on which version and which lifecycle policy you are on right now.
We establish where your GP environment actually sits, what carries across, what has to be rebuilt, and what a realistic timeline looks like before you commit to a project.
6 Solutions Partner Designations
Including Business Applications
Dynamics GP 2018 R2 and earlier follow Microsoft's Fixed Lifecycle Policy, with five years of mainstream support and five of extended. GP 18.2 and later moved to the Modern Lifecycle Policy, which runs to a single announced end date instead.
Most GP users assume they have until 2029. Many do not, and a significant number are already outside support without realizing it.
Source: Microsoft product lifecycle documentation. One detail catches a lot of GP 2018 users out: installing any current tax release or hotfix moves you to version 18.5 or later, which places you on the Modern Lifecycle Policy. If you have applied a recent tax update, the January 2028 date may no longer be the one that applies to you.
New perpetual licenses for Dynamics GP are no longer sold.
New subscription licenses ended. Existing customers can add users but cannot start new GP instances.
Product enhancements, regulatory and tax updates, service packs and technical support all end.
Security updates end, along with subscription billing and SPLA use of Dynamics GP.
This is the single most important difference between a GP migration and a NAV one. NAV has a version-by-version upgrade path into Business Central. GP has no such path, because the two products were never built on the same application code.
What you are running is a reimplementation with a data migration attached, and budgeting it as an upgrade is how GP projects go wrong.
Your companies, segmented chart of accounts, Dexterity and VBA modifications, ISV add-ons, payroll, and years of transaction history.
We inventory modifications, add-ons, integrations and data quality, then decide what is rebuilt in standard Business Central, what needs an extension, and what retires here.
Where scope is setBusiness Central is configured around your processes, then master data, open balances and agreed history are migrated, validated and reconciled against GP.
Continuous updates, no end-of-support date to plan around, and access to Power Platform, Power BI and Copilot.
Why December 2029 is the wrong date to plan around: a GP migration typically runs six to twelve months, and most organizations spend another three to six months before that on evaluation and internal approval. Treating 2029 as the deadline means starting in 2028 at the latest, and going live during a year-end close nobody wants to risk. The practical window is narrower than the headline date suggests.
Two companies on the same GP version can have completely different projects. The variables below are what separate a five-month migration from a fourteen-month one, so we inventory every one of them before quoting anything.
GP's segmented account framework does not map one to one onto Business Central, which uses dimensions instead. This is usually the first real design decision, and it shapes every report that follows.
Custom Dexterity code, Modifier changes and VBA scripts have no equivalent in Business Central. Each one is assessed for a standard replacement, a Power Platform alternative, an AL extension, or retirement.
GP estates typically carry several third-party products for payables automation, document management, bank reconciliation or reporting. Each gets checked for a Business Central version, a replacement, or retirement.
Business Central online has no native US payroll module. If you run payroll inside GP, that function moves to a dedicated payroll provider or an ISV. We would rather raise this in week one than in month seven.
Integration Manager routines, eConnect connections, EDI, banking files, shipping, CRM and custom SQL jobs are inventoried and tested. These are usually the connections nobody documented.
Management Reporter statements, SmartLists, SSRS reports and the spreadsheets built on top of them are catalogued and rebuilt using Business Central reporting and Power BI.
You decide what moves, what gets archived, and what stays queryable in a read-only copy. Carrying twenty years of GP transactions across costs real time, and often a reporting archive serves the same purpose for less.
GP estates often run separate databases per legal entity with inconsistent setups between them. Consolidating or keeping them separate in Business Central is a decision with real cost attached either way.
Business Central online authenticates through Microsoft Entra ID. GP user accounts, security roles and task-level permissions are re-established rather than transferred, which is also a chance to fix what has drifted.
Anyone quoting a GP migration before seeing your environment is guessing. What we can give you upfront are honest planning bands based on how complex the estate turns out to be, then a defined scope once we have looked.
One or two companies, limited modification, few add-ons, payroll already outsourced, and a decision to leave most history in an archive.
Several companies, meaningful Dexterity or VBA work, multiple add-ons and live integrations, and a chart of accounts that needs redesigning rather than copying.
Many entities, in-house payroll to replace, heavy modification, industry add-ons, EDI and warehouse connections, and a data estate needing real transformation.
We assess your GP version and lifecycle position, companies, modifications, add-ons, payroll, integrations, reporting and data, then hand you a defined scope, a realistic timeline, and an implementation plan. You own the output whether or not we run the migration.
Tell us which GP version you are running, how many companies you have, and whether payroll sits inside it. We will walk through what your migration involves, what needs a decision, and how long a project like yours typically takes.
Everything you need to know about migrating from Dynamics GP to Business Central.
It depends on your version. GP 2013 left support in April 2023, GP 2015 in April 2025, and GP 2016 on 14 July 2026, so those are already unsupported. GP 2018 and 2018 R2 run to 11 January 2028. Versions 18.2 and later sit on Microsoft’s Modern Lifecycle Policy, which ends 31 December 2029, with security patches to 30 April 2031. One detail catches many GP 2018 users out: installing a current tax release or hotfix moves you to version 18.5 or later, which places you on the Modern Lifecycle Policy instead.
No. Unlike Dynamics NAV, which has a version-by-version upgrade path into Business Central, GP and Business Central were never built on the same application code. A GP move is a reimplementation with a data migration attached: Business Central is configured around your processes, and your master data and balances are migrated into it. Budgeting the work as an upgrade rather than a reimplementation is the most common way GP projects go over.
None of it transfers. Dexterity code, Modifier changes and VBA scripts have no equivalent in Business Central, which uses AL extensions. We review each modification and give it a decision: replace it with standard Business Central functionality, rebuild it as an extension, deliver it through Power Platform, or retire it. In practice a meaningful share of GP customizations exist to fill gaps that Business Central already covers, so the list usually gets shorter, not longer.
This is the question most GP pages avoid. Business Central online has no native US payroll module, so if payroll runs inside GP today it moves to a dedicated payroll provider or a payroll ISV, integrated back into Business Central for the general ledger postings. Vendor 1099 reporting is handled in Business Central, but your vendor records and 1099 setup need reviewing rather than assuming they carry over. We raise both in the first assessment, not in month seven.
You can, but it is rarely the right call. Master data, open balances and an agreed window of history typically migrate, while older transaction history is often better kept in a read-only archive you can still query. Two GP specifics shape this: your segmented chart of accounts maps onto Business Central dimensions rather than one to one, and GP estates with separate databases per company need a decision on whether those stay separate. Both are design decisions, not data tasks.
A straightforward environment typically runs 4–6 months, a moderate one 6–9 months, and a complex estate 9–14+ months. The biggest factors are the number of GP companies, the volume of Dexterity and VBA modification, ISV add-ons, whether payroll sits inside GP, integration count, chart of accounts redesign, and how much history moves. Our fixed-scope assessment reviews all of these and hands you a defined scope, timeline and implementation plan before you commit to the project.
Still have questions? Our experts are here to help.
Talk to an ExpertWe're taking you to ERBrains USA in 5 seconds.
