Dynamics GP end of support is scheduled for December 31, 2029, but waiting until that deadline to plan an ERP cloud migration can increase cost, complexity, and risk. Supporting technologies may reach the end of support sooner, while customizations, security exposure, and competition for experienced migration partners continue to grow.
Read on to learn why delaying a Dynamics GP migration can increase costs and what you can do now to prepare.
The GP Deadline Might Not Be Your First to Consider
Most discussions about Dynamics GP focus on December 31, 2029, when product enhancements, regulatory and tax updates, and technical support end. But that can create a false sense of security because Dynamics GP is only one part of a larger technology stack. Several supporting systems reach critical milestones much sooner.
Key Dates to Know
| Date | Milestone |
| July 14, 2026 | SQL Server 2016 reaches end of extended support. Microsoft no longer provides regular security updates or technical support; paid extended security updates run to July 2029. |
| April 1, 2026 | Final day for new customers to license Dynamics GP subscriptions. |
| January 12, 2027 | Windows Server 2016 extended support ends. Extended Security Updates are available through Azure Arc. |
| December 31, 2029 | Dynamics GP product enhancements, regulatory and tax updates, and technical support end. |
| April 30, 2031 | Service plan coverage ends. Additional perpetual users on existing Dynamics GP systems can no longer be added. |
Don’t plan your future based on the last date in the sequence. By the time Dynamics GP reaches its support deadline, both SQL Server 2016 and Windows Server 2016 will have been operating outside their standard support windows for years.
Why Does Delaying a Dynamics GP Cloud Migration Cost More?
1. Security Exposure Stops Being Theoretical
Older systems are harder to secure. As support and updates become less predictable, teams spend more time and expertise identifying and addressing vulnerabilities.
A July 2026 vulnerability in Dynamics NAV 2018 shows the risk. Microsoft rated CVE-2026-55944 at 9.8 because attackers could exploit it without authentication or user interaction. Microsoft released a fix separate from the latest cumulative update, but as a result, you could follow the normal patching process and still remain vulnerable.
2. Customizations and Integrations Continue to Grow
Every customization creates a decision: rebuild it, replace it, retire it, or redesign the process entirely. The more exceptions and undocumented workarounds pile up, the more discovery work the project needs before it can start.
It’s is also one of the reasons that ERP projects exceed their original budgets. Scope discovered during implementation is typically more expensive than scope identified during planning.
3. The People Who Know the System Move On
Essential knowledge of legacy ERPs sometimes exists only with long-term employees:
- One person knows why a posting routine was customized a decade ago.
- Someone else understands the manual step required before month-end close.
- A third person remembers why a particular integration was built in the first place.
When key stakeholders leave before migration planning begins, project teams often have to rediscover information that was once readily available.
4. Partner Capacity Compresses Toward the Deadline
As 2029 approaches, more companies will be evaluating migration projects, looking for experienced GP consultants, and competing for implementation resources at the same time.
If you start planning earlier, you’ll have more time to evaluate partners and schedule projects around your business priorities. Those that wait until the final wave of migrations, may have fewer options and less control over timing.
5. The Capability Gap Widens Every Release
The cost of waiting isn’t just limited to future migration expenses. Every year spent on a legacy platform can widen the gap between what you’re still doing manually and you’re your competitors have automated.
As cloud-native ERPs evolve, Microsoft reports that Business Central has now surpassed 55,000 cloud customers, and that roughly half of those have used Copilot and at least one Business Central agent. These are capabilities teams can’t explore on legacy platforms like GP or NAV.
How Long Does a Dynamics GP-to-Business Central Migration Take?
A Dynamics GP-to-Business Central migration can require about 18 months of evaluation, implementation, and stabilization, before accounting for delays or process redesign. Companies that want to be fully migrated before Dynamics GP support ends should work backward from December 31, 2029, rather than treating the deadline as the date to begin planning.
Three years sounds like plenty. But evaluation, planning, implementation, testing, training, and stabilization all have to fit inside it. Look at these six drivers that play a role in determining both cost and time.
Let’s consider a hypothetical mid-market company that wants to be fully migrated and stabilized before Dynamics GP support ends on December 31, 2029. The company spends:
- 6 months evaluating ERP options, selecting an implementation partner, documenting requirements and dependencies, aligning internal stakeholders, and preparing the data and project team
- 9 months configuring Business Central, migrating, and validating data, rebuilding necessary integrations, testing business processes, training users, and preparing for go-live
- 3 months resolving post-launch issues, refining workflows, supporting users, completing follow-up training, and helping teams adopt the new system in their daily work
Those efforts have consumed 18 months. If the project encounters delays or requires significant process redesign, it’s likely to take even longer. Suddenly, the premise that a GP migration can be put off until next year, or the year after, becomes a risky assumption.
Why the Works Cafe Didn’t Wait for the GP Deadline
Rather than waiting for GP’s eventual sunset to dictate their timeline, The Works Cafe chose to move proactively. The business had reached a point where GP no longer matched the pace or complexity of the business behind it.
The impact of the move was immediate. Financial reporting that once took hours now runs in minutes inside Business Central. The finance team no longer needs IT support, or backend ledger pulls to get answers. Read the entire case study to learn more about why The Works Cafe chose to move beyond GP now, and how they are realizing quantifiable gains.
What Are You Losing by Waiting?
Delaying a Dynamics GP migration also delays the potential financial and operational gains of Business Central. A Forrester Total Economic Impact study published in March 2026 found that a composite organization using Business Central:
- Achieved a modeled 209% ROI over three years
- Paid back its investment in less than six months
- Recognized $464,000 in net present value (projected benefits minus costs)
- Saved 30 percent in monthly close time
- Saved 50 percent of the time spent on AP, AR, and billing by the third year
Every year that organizations wait is another year without those potential gains, and another year spent maintaining aging infrastructure, manual workarounds, and legacy processes.
What Should Dynamics GP Users Do in the Next 90 Days?
You don’t need an approved budget or a signed implementation agreement to begin preparing for a migration. Start by eliminating uncertainty, so you can make decisions based on facts rather than assumptions.
1. Confirm Which Support Policy Applies to Your GP Environment
Not every Dynamics GP environment follows the same lifecycle timeline. Start by documenting your current GP version and verifying its support status against Microsoft’s Dynamics GP lifecycle guidance. Understanding your actual timeline is the foundation for every decision that follows.
2. Inventory the Technology Supporting GP
Many organizations know their ERP version but have less visibility into the systems underneath it. Document:
- SQL Server version
- Windows Server version
- Hosting environment
- Third-party applications
- Critical integrations
Doing so often reveals risks and dependencies that aren’t visible when looking at the ERP alone.
3. List Your Customizations and Integrations
Create an inventory of:
- Custom reports
- Third-party add-ons
- Power Automate workflows
- Data integrations
- Spreadsheet-dependent processes
- Manual workarounds
Migration projects become more predictable when organizations discover these dependencies before implementation instead of during it.
4. Capture Institutional Knowledge
Identify the people who understand how key processes actually work. Document:
- Why customizations were created
- Which processes require manual intervention
- Which reports are business-critical
- Which workarounds have become standard operating procedures
The knowledge behind a process is often more valuable than the process itself. Capturing it now can prevent costly rediscovery later.
5. Assign an Internal Owner
A successful modernization effort starts with clear ownership. That owner needs responsibility to coordinate stakeholders and move planning forward. Without an owner, migration preparation tends to stall; with an owner, it becomes an active initiative.
The organizations that navigate the Dynamics GP transition most successfully are the ones that start planning before the deadline forces the conversation.
Are You Ready to Start Planning?
The best time to build a migration plan is before you’re forced to do so. The longer you wait, the more likely it is that supporting infrastructure, security requirements, customizations, staffing changes, and growing technical debt will shape the project for you.
If your organization is primarily focused on core financials, JourneyTeam’s Sherpa Program for Business Central provides a structured approach to moving from legacy ERP systems to the cloud.
If you have multiple entities, heavy customization, or complex integrations, we can help you clarify where you stand and what a realistic timeline to Business Central might look like. Reach out today!
