Dynamics GP end of life: what the 2029 deadline actually means for your next 12 months
New Dynamics GP subscription licenses stopped being sold on April 1, 2026. GP 2016 and 2016 R2 lost extended support on July 14, 2026. If your organization is still running GP, the number circulating in most conversations, December 2029, is not the number that should be driving this year's planning calendar.
The Dynamics GP end-of-life timeline is real, but it unfolds in stages, and the stage that matters to you depends on which version you run and how complex your environment is. This post lays out the full support timeline, explains why 2029 is a misleading planning target, walks through what a GP to Business Central migration actually involves, and gives you a way to tell whether your organization needs to start now or can reasonably wait.
The real Dynamics GP support timeline (not just the headline date)
Microsoft has been retiring Dynamics GP in phases since 2025, and each phase closes a door for a different group of customers.
Perpetual license sales ended April 1, 2025, and new subscription license sales ended exactly one year later, on April 1, 2026, according to Microsoft's Dynamics GP lifecycle policy. Neither cutoff affects organizations with an active GP subscription or enhancement plan; you can still add users and stay supported. What it means is that no new company can start on GP today, which is itself a signal about where Microsoft is putting its investment.
Version-specific support is the part most organizations overlook. GP 2016 and GP 2016 R2 moved out of mainstream support back in 2021, and extended support for those versions ended July 14, 2026, according to Microsoft's Dynamics GP lifecycle policy. If you're running one of those builds, your support window has already closed, regardless of what the 2029 headline suggests.
For everyone else, mainstream support, meaning product enhancements, regulatory and tax updates, and standard technical support, ends December 31, 2029. According to Stoneridge Software's coverage of the update, Microsoft pushed this date back from an earlier September 2029 target specifically so payroll customers wouldn't be caught mid-fiscal-year. After that, security patching continues on a limited basis until April 30, 2031, per Microsoft's Dynamics GP lifecycle policy, but ordinary bug fixes and tax table updates stop.
Two sales cutoffs have already passed, and one version's support has already lapsed. The two dates most people quote, 2029 and 2031, apply only to organizations still running current, actively maintained builds of GP.
Why "2029" is misleading for planning purposes
Treating December 2029 as the deadline assumes you can start a migration in, say, October 2029, and be finished by year end. That assumption doesn't hold up against how these projects actually run.
According to migration timeline analysis published by ERP Software Blog, a Dynamics GP to Business Central migration involving chart of accounts redesign, integration rebuilds, and user retraining typically takes 9 to 18 months from discovery to go-live. Simpler environments with clean data and few customizations can move faster; environments with years of accumulated customization, multiple integrations, and large transaction histories run longer. Either way, if 2029 is your hard stop, your realistic start date is sometime in 2027 or early 2028, not 2029.
There's a second pressure that compounds the first. Every organization still on GP is watching the same calendar, which means implementation capacity will not stay flat as the deadline approaches. Consultants who specialize in GP's underlying Dexterity customization stack are a shrinking pool, and demand for Business Central implementation partners is already rising. Organizations that wait until 2028 or 2029 to start looking for a partner will be competing for the same limited set of experienced hands as thousands of other companies hitting the same wall at the same time. That competition shows up as longer wait times, higher project costs, and less partner choice, not as a friendlier market.
Put together, the effective planning deadline sits well before the headline date, and it moves earlier the more customized or complex your GP environment is.
What a GP to Business Central migration actually involves
It helps to be specific about where the time goes, because "migration" undersells how much of this work is redesign rather than data transfer.
Chart of accounts and dimension mapping is usually the first real decision point. Most GP charts of accounts have accumulated years of ad hoc account creation, and Business Central's dimension model works differently enough that a straight one-to-one copy rarely makes sense. Organizations running Dynamics NAV face a parallel decision here. A NAV to Business Central migration involves the same chart of accounts and dimension mapping exercise, just against NAV's table structure instead of GP's. In both cases, treating this step as a chance to clean up years of reporting debt, rather than a compliance formality, tends to pay off well past go-live.
Integration rebuilds are the second major cost center. Point-to-point integrations built against GP's data model, whether to a warehouse system, a payment processor, or a reporting tool, generally need to be re-architected against Business Central's APIs rather than simply repointed. Skipping a proper inventory of these integrations is one of the more common reasons fixed-price migration quotes end up short.
Retraining rounds out the list, and it's easy to underbudget. Business Central's interface and workflows differ enough from GP that finance and operations staff need real training time, sequenced so people aren't trained too early and forget the workflow, or too late and go live undertrained. Payroll and inventory processes, in particular, tend to carry the most business-specific configuration and the highest cost if something goes wrong right after go-live.
How to tell if you should start now or can safely wait
Not every GP customer needs to move this year. A few questions will tell you which camp you're in.
Start with your version. If you're on GP 2016 or 2016 R2, you're already past your support window, and this isn't a 2029 conversation at all. Complexity matters next, since significant customizations, multiple system integrations, or a large transaction history push your realistic timeline toward 18 months, meaning a 2029 go-live requires starting the assessment now. Finally, look at your calendar.
A fiscal year-end or major regulatory filing cycle in the next 12 months is easier to sequence a migration around than through.
If your environment is relatively clean, on a currently supported GP version, with modest customization, you likely have more room to plan deliberately over the next 18 to 24 months rather than react immediately. The point isn't to panic. It's to know honestly which category you're in before the calendar makes the decision for you.
What to do next
A short checklist, before you commit to a timeline:
Confirm your current GP version and whether it's still in mainstream or extended support.
Inventory your customizations, integrations, and data volume. This is the input every later estimate depends on.
Map your fiscal year and any regulatory deadlines against a realistic 9 to 18 month project window.
Identify whether chart of accounts or dimension redesign is on the table, since that decision shapes scope early.
Start partner conversations before 2027, ahead of the capacity crunch that will hit as 2029 approaches.