If your business is still running Dynamics GP, you’ve probably already heard the headlines. New license sales stopped in April 2026. Support winds down at the end of 2029. Security patches stop in 2031. Most of that is old news by now, and honestly, most of the articles written about it read the same way: here are the dates, here’s why you should be worried, here’s why you should call us.
That’s not this article.
What actually matters heading into 2027 isn’t another recap of Microsoft’s timeline. It’s a much more practical question: what does a business actually do with that timeline? Not in five years. Not “eventually.” In the next twelve months, as budgets get set, headcount gets planned, and someone in finance asks what’s actually in the ERP line item for next year.
This is what we think belongs in that conversation, based on what we’ve seen work, and what we’ve seen go wrong, for businesses navigating this exact stage of the GP lifecycle.
Where Things Actually Stand Right Now
Quickly, so we’re all working from the same facts: Dynamics GP is no longer sold to new customers. Existing customers can keep using it, and Microsoft is still providing support and updates through the rest of the decade, but the runway is finite and clearly marked. Product enhancements, tax updates, and technical support continue through the end of 2029. Security patches follow through April 2031.
That’s not a cliff. It’s a slope, and 2027 sits right in the middle of it. Not urgent enough to panic, but close enough that “we’ll deal with it later” starts to look like a real decision with real consequences, whether you meant it that way or not.
For the full timeline and what each milestone actually means, see our detailed breakdown of Dynamics GP end of support.
Why 2027 Is the Year That Actually Matters
Here’s the thing most GP customers get wrong: they treat this as a single decision to make someday, rather than a series of smaller decisions that need to happen on a schedule. Waiting until 2029 to start planning a migration means starting a 12 to 18 month project with less than a year of true runway left before support winds down completely. That’s not a plan. That’s a scramble with a deadline attached.
2027 is the year most businesses still have real breathing room. You can plan a migration on your own timeline, budget it across a normal planning cycle, and avoid the compressed, expensive, high-stress version of this project that a lot of your peers are going to end up running in 2028 and 2029, when the calendar stops giving them a choice.
Whether your business ends up migrating in 2027, 2028, or later, the planning itself should not wait. Here’s what that planning should actually include.
What Should Be in Your Business Plan
1. A Real Line Item, Not a Placeholder
Most GP customers have some version of “ERP transition” sitting in a five-year plan somewhere, usually with a rough number attached that hasn’t been revisited since it was first written down. That’s not a budget. That’s a placeholder that gives false comfort.
A real 2027 business plan should include an actual, current estimate for what a Business Central migration would cost your specific organization, based on your transaction volume, your customizations, and your integrations, not an industry average pulled from a blog post. It should also account for the costs that don’t show up on a software quote: internal staff time, temporary productivity dips during go-live, and training. Those hidden costs are usually where migration budgets go wrong, not the licensing itself.
2. An Honest Risk Assessment, Written Down
Most businesses know, informally, that staying on unsupported software is risky. Very few have actually written that risk down anywhere leadership or the board would see it.
Your 2027 plan should include a documented answer to a simple question: what happens to this business if GP has a critical security issue after support ends, and no patch is coming? What does that mean for compliance, for cyber insurance, for customer trust, for audit findings? Writing that answer down, even a rough one, tends to change how urgently a company treats the rest of this list. It also gives you something concrete to point to when budget conversations get difficult later.
3. A Skills and Staffing Plan
This one gets missed constantly, and it’s becoming a bigger problem every year. As more businesses move off GP, the pool of consultants, developers, and internal staff who deeply know the platform keeps shrinking. The people who do know it well are getting harder to hire, more expensive to retain, and closer to retirement than they were five years ago.
If your GP environment depends on one or two people, internal or external, who understand its customizations, that’s a staffing risk worth naming explicitly in your plan, separate from the software risk itself. Ask directly: if that person left tomorrow, how exposed would we be? For a lot of businesses, the honest answer is uncomfortable, and that discomfort is useful information for planning purposes.
4. A Data and Archiving Strategy, Regardless of Timing
Here’s something that applies no matter when you actually migrate: your historical GP data needs a plan of its own. Years of transactions, financial history, and audit trails don’t just need to survive a migration someday, they need a clear policy today around retention, access, and backup, especially the longer you stay on an aging system.
This is worth separating from the broader “should we migrate” conversation, because it’s not really optional. Decide now how long you need to retain historical data, who needs access to it and how, and what your backup and recovery plan looks like in the meantime. That answer should exist whether your migration happens in 2027 or 2030.
5. A Security Patching Cadence for the Interim Years
If migration isn’t happening in 2027, your plan still needs to address how your organization will handle security through the years GP remains supported, and what changes once it isn’t. That includes confirming your current patching cadence is actually being followed (not just assumed), reviewing what compensating controls exist around your GP environment, and setting a clear internal trigger point, a specific date or event, that forces a re-evaluation of your plan rather than letting the decision drift by default.
6. A Budget Cycle That Actually Aligns with the Timeline
One of the most common planning mistakes is treating GP’s timeline and your normal IT budget cycle as two separate things. They’re not. If your organization plans budgets annually, 2027’s plan should explicitly map out which fiscal year a migration would realistically fall into, based on your risk tolerance and the size of the project, so it isn’t competing for last-minute funding against other priorities that had more lead time to build their case.
What Not to Do
A few patterns we see repeatedly, worth naming directly:
Don’t wait for a burning platform moment – Some businesses are, understandably, waiting for something to actually break before they act. The problem is that by the time something breaks badly enough to force a decision, you’ve lost the ability to plan on your own terms, and you’re making rushed choices under pressure instead of informed ones.
Don’t treat this as a pure IT project – A GP to Business Central transition touches finance, operations, and often sales, not just the systems team. Planning that happens entirely inside IT, without input from the departments actually using the system daily, tends to produce migrations that are technically successful and operationally rocky.
Don’t budget for software and stop there – As covered above, the software subscription is rarely the number that actually determines whether a migration goes smoothly. Training, data cleanup, and internal time are where budgets get blown, and they’re exactly the line items most likely to get skipped in an early estimate.
A Simple Way to Frame the Decision
Every GP customer heading into 2027 is really choosing between three paths, whether they’ve said it out loud or not:
Plan and migrate in the near term – You control the timeline, budget it properly, and avoid the compressed, high-pressure version of this project.
Plan now, migrate later – You do the risk assessment, staffing review, and budget mapping this year, but intentionally schedule the actual migration for a future cycle, with a real plan behind that decision instead of just inertia.
Continue without a real plan – You keep running GP, keep deferring the conversation, and accept the risk without ever writing it down or deciding on purpose. This is the path most businesses are on by default, not by choice, and it’s the one that tends to produce the worst outcomes when the timeline finally forces a decision.
The first two are legitimate business decisions. The third one isn’t really a decision at all, it’s just what happens when nobody makes one.
How Nevas Technologies Can Help
Whether your business is planning a migration for 2027 or building a longer runway before you make that move, the planning itself shouldn’t be guesswork. Nevas Technologies has spent over 20 years helping businesses navigate exactly this stage of the Dynamics GP lifecycle, with 200+ clients and a team of certified Microsoft Dynamics consultants who can help you build a plan grounded in your actual environment, not a generic timeline.
Here’s how we help:
- A structured assessment of your current GP environment, customizations, and integrations, so your budget estimate reflects your business, not an industry average
- An honest risk review you can actually bring to leadership or the board
- Guidance on staffing and skills exposure specific to your GP setup
- A data retention and archiving strategy that holds up regardless of when you migrate
- A realistic migration roadmap and budget mapped to your actual fiscal planning cycle, when you’re ready to move
Frequently Asked Questions
Do I need to migrate off Dynamics GP in 2027?
Not necessarily. What matters in 2027 is having an actual plan, whether that plan includes migrating soon, migrating later on a defined timeline, or documenting why you’re staying on GP for now. The risk comes from having no plan at all, not from choosing a later migration date on purpose.
What’s the biggest planning mistake businesses make with Dynamics GP right now?
Treating this as a single future decision instead of a set of smaller decisions that need attention now: budgeting, risk documentation, staffing exposure, and data strategy. Waiting until support fully ends to start any of that planning leaves very little room to do it well.
How much should we budget for a GP to Business Central migration?
It depends heavily on your transaction volume, customizations, and integrations, so there’s no single reliable number. A proper assessment of your specific environment is the only way to get a budget estimate worth planning around.
What happens if we just keep running GP past 2029?
The system will likely continue to function, but without product updates, tax changes, or vendor support after that point. Security patches continue a bit longer, through April 2031, but running unsupported software indefinitely carries growing operational, security, and compliance risk that tends to compound the longer it goes undocumented and unaddressed.
Next Steps
2027 doesn’t have to be the year your business migrates off Dynamics GP. But it should be the year you actually decide, on purpose, what your plan is, instead of letting the calendar decide for you.
Schedule a free GP environment assessment with our Microsoft Dynamics team to start building a real plan, or get a custom quote if you’re ready to talk timeline and budget.
