The GP migration window is open until 2029 but that’s the wrong deadline to plan around
Most businesses running on Microsoft Dynamics Great Plains (GP) have a date in their heads: December 2029. That’s when Microsoft ends Mainstream Support. Extended Support runs to April 2031. So there’s time. Plenty of it, arguably.
But having time and having a good outcome are not necessarily the same thing.
Startling when the deadline forces the issue is not the way to win in the transition to Microsoft Dynamics 365 Business Central. A better strategy is to start while you still have options. That window – the one where you have options – is narrower than the support timeline suggests.
The GP support timeline isn't the planning timeline
December 2029 feels like a long way off. For most businesses, it registers as a background fact rather than an active constraint. Something to deal with eventually.
But here’s what that framing misses: the support deadline is the last possible moment, not the right one. And the distance between those two things is where migrations go wrong.
A well-managed GP-to-Business Central migration isn’t a switch. It’s a complex project that involves:
- Data mapping and cleansing. Years of transactional history, customisations, and integrations don’t move themselves. The messier your current environment, the more time this takes.
- Configuration and testing. Business Central needs to be set up to match how your business is running today. That’s a process, not a setting.
- User training and adoption. Post-migration success hinges on preparing teams to win. Change management takes time and attention.
Is upgrading GP worth it?
Most businesses that defer the migration conversation aren’t doing nothing. They’re continuing to invest in GP, even if that investment no longer makes sense given the direction of travel.
A leading South African power tools and equipment distributor estimated that upgrading their existing installation would have cost 80–85% of a full migration. With none of the upside. That’s a strong argument for making sure you’re spending money in the right direction.
The other cost of waiting is less visible but compounds faster: every year on GP is a year your competitors on Business Central are accumulating AI capability and platform improvements that ship automatically. That divide doesn’t reset when you eventually migrate.
Two versions of the same GP to BC migration
Every GP-to-Business Central migration ends in the same place, ideally. But the journey to that point can differ drastically, with lead time being one of the major deciding factors.
The planned migration looks like this:
- Discovery and scoping happen over weeks, not days. Your current environment gets properly mapped: customisations documented, integrations inventoried, data quality assessed before anyone starts moving anything.
- Configuration is done to match how your business operates. Edge cases get addressed in testing, not after go-live.
- Training is embedded into the project timeline. Your finance team, operations team, and any other users aren’t handed a new system on a Monday morning. They’ve been in it, in a test environment, for weeks.
- Go-live is a known date, planned around your business cycle. A moment chosen because it makes sense, whether or not it coincides with month-end or peak season.
- Post-go-live support is structured and available. When questions come up, there’s a clear process for resolving them quickly.
The pressured migration looks like this:
- The timeline is set by the deadline, not the project. Everything gets compressed to fit.
- Data cleansing gets deprioritised because there isn’t time. You migrate the mess.
- Configuration decisions get made quickly, which means they get made with incomplete information. Some of those decisions are hard to unpick later.
- Training gets reduced to the minimum. Users go live anxious and underprepared. Productivity drops sharply in the weeks after go-live, sometimes for months.
- Your implementation partner is stretched, because everyone is running the same race at the same time.
| Planned migration | Pressured migration | |
|---|---|---|
| Discovery | Weeks of scoping. Environment fully mapped before anything moves. | Compressed to fit the deadline. Partial at best. |
| Data | Cleansed and structured ahead of migration. You move clean data. | Deprioritised. You migrate the mess. |
| Configuration | Built to match how your business operates. Edge cases resolved in testing. | Decisions made fast, with incomplete information. Hard to unpick later. |
| Training | Embedded into the project timeline. Teams go live confident. | Reduced to the minimum. Productivity drops, sometimes for months. |
| Go-live | A date chosen to suit your business cycle. | Set by the deadline, not the project. |
| Post go-live | Structured support in place. Issues resolved quickly. | Problems surface without a clear resolution path. |
| Partner capacity | Full attention. Right resources, right pace. | Stretched. Everyone running the same race at the same time. |
Early movers are winning on Business Central
While this conversation is happening, something else is happening in parallel.
Businesses that migrated to Business Central a year ago, two years ago, three years ago, are accumulating advantages that compound.
Microsoft ships two major Business Central updates per year. Every one of those updates brings new Microsoft Copilot capabilities, new automation features, new integrations. Businesses already on the platform receive them automatically.
The head start for a business already on Business Central takes shape in every corner of the organisation:
- Their finance team is using Copilot to draft journal entries, summarise variance reports, and flag anomalies before month-end becomes a scramble.
- Their operations team is querying live inventory data in plain language, getting answers in seconds that previously required a report request and a wait.
- Their leadership team has AI-assisted forecasting and scenario modelling available inside the same system their team uses every day.
- Their IT function is carrying less, because they’re not managing patch management or planning hardware refreshes.
None of that is available to a business still running on GP. And by the time a GP customer migrates under deadline pressure in 2030 or 2031, the businesses that moved in 2025 or 2026 will have had five or six years of compounding advantage to show for it.
The market will get crowded
Supply is another variable that rarely makes it into the migration planning conversation.
As December 2029 gets closer, every GP customer in the region will be having the same conversation at the same time. Implementation can only succeed on the back of skilled consultants and data migration specialists, and that capacity is finite.
Businesses that wait long enough won’t just be competing with a deadline. They’ll be competing with each other for the partners who can do the work properly.
When to start your GP migration (the answer isn't 2029)
For most South African businesses, staying on GP is, at best, a decision to defer the inevitable. And the longer it’s deferred, the more it shapes what’s possible, operationally, and in terms of AI readiness.
The window to do this well is open now. It won’t stay that way indefinitely, and the cost of a compressed migration is both high and completely avoidable.
If that’s a conversation your leadership team is starting to have, the Braintree Dynamics Discovery Assessment is how we make it concrete. A structured look at your current GP environment, an honest view of what migration would involve, and a documented roadmap your board can act on.
Book a Dynamics Discovery Assessment with Braintree
