Dynamics GP: the capacity problem behind the deadline
There is no shortage of writing about the end of Dynamics GP. Almost all of it is addressed to the GP customer, and almost all of it says the same thing, which is that 2029 is closer than it looks and the time to plan is now.
That advice is sound. It also creates a second problem that nobody is writing about, and it belongs to the partner rather than the client.
If every GP customer takes the advice, the demand for Dynamics GP to Business Central migration arrives as a block rather than a stream. For any partner holding GP clients, the constraint stops being whether the move makes sense and becomes whether there is anyone free to deliver it.
The dates that matter
Microsoft's lifecycle documentation sets the end of Dynamics GP support at 31 December 2029, covering product enhancements, regulatory and tax updates, and technical support. Security updates continue until 30 April 2031. The 2029 date has already moved once, having previously been announced as 30 September 2029.
Those dates apply to versions covered by the Modern Lifecycle Policy. Older versions sit under the Fixed Lifecycle Policy and have their own earlier end dates, several of which have already passed. A partner with a GP client base will usually find at least one client running something that is no longer supported at all.
GP does not stop working on any of these dates. What stops is the flow of tax and regulatory updates, which is the part that matters to a finance team and the part that turns a deferred IT decision into a compliance conversation.
Where the pressure sits
Work out the sequence and the partner-side problem becomes visible.
A client reads one of the many articles telling them to start early. They come to you in 2027 with a decision already made. So does the next one. The clients who waited arrive in 2028 and 2029, by which point you are quoting availability rather than scope.
Recruiting through that period does not solve it. Every other partner in the market is trying to hire the same people at the same time, for a window of work that closes in 2029. Hiring into a spike is an expensive way to be caught with capacity you no longer need in 2030.
Turning the work away is the other option, and it has a cost that shows up later. A GP client handed to someone else is a client who now has a relationship with someone else.
The arithmetic on effort
The reason GP migrations consume so much time is not complexity for its own sake. It is that legacy on-premise finance data does not lift cleanly into a modern structure. Chart of accounts, dimensions, open balances, customers, vendors, items, all of it has to be extracted, understood, mapped and checked before any of the work a client actually values can begin.
For a partner, this stage carries the worst ratio in the engagement. It absorbs senior time, it generates no visible progress for the client, and it is the part clients are least willing to pay for at the rate it costs to deliver.
It is also the part that repeats almost identically from one client to the next.
What automation changes
Qwyk is a Business Central onboarding and support platform built for Microsoft Partners, and Dynamics GP is a live source system on it today.
The platform connects to the source, extracts the data, maps it to Business Central with AI assistance, and runs quality checks before anything reaches a live environment. On-premise GP installations without an API are handled through a lightweight agent installed on the machine holding the data. Everything lands in a fully audited sandbox first, and production is only written to when the partner pushes the sandbox live, which is a single step. A basic onboarding from a supported source system can take as little as 30 minutes.
How involved you are is your decision. You can run the migration yourself through the partner portal. You can hand it to the client to self-serve through a guided wizard. Or Qwyk can manage it on your behalf, which is the mode most partners use when volume arrives faster than their own calendar allows. The client relationship stays with you throughout, and the client sees you rather than Qwyk.
For a partner looking at a GP book that all needs moving inside the same three years, the useful part is that the migration stage stops scaling with headcount.
The smaller GP clients
There is a second effect worth planning for.
Most partners carry GP clients who have never been worth a full migration proposal. The deal is too small to justify the manual setup time, so the conversation gets deferred, and deferred again, until the client eventually finds someone else or runs the software until it stops being supported.
When the foundation is automated, the economics of those engagements change. Work that could not carry the cost of a traditional implementation becomes viable, which matters when the same deadline is pushing every client in the book towards a decision at once.
For most partners this is the part of the GP wave that would otherwise be written off entirely.
What it does not remove
Automating the migration does not turn a GP migration into a trivial exercise, and it would be a poor argument to suggest otherwise.
Decisions about how a client's chart of accounts should be restructured in Business Central still need someone who understands the business. Customisations built up over fifteen years still need assessing, and some need rebuilding as extensions. Integrations to warehouse, EDI, payroll or reporting tools still need rethinking. Users still need training, and finance teams still need a parallel run they trust before they will sign off a year end on a new system.
What changes is where the consultant's hours go. The extraction and mapping stage runs on the platform. The judgement work, which is the part clients value and the part that justifies the rate, stays with the partner.
That shift is what makes a concentrated wave of GP work deliverable by the team you already have.
Where to start
The first piece of work is not a migration. It is a list.
Which of your clients run Dynamics GP, which version, and whether that version sits under the Modern or Fixed Lifecycle Policy. Anything under Fixed Lifecycle needs checking against Microsoft's published dates, because some of those clients are already running unsupported software and do not know it.
Sequence the list by complexity rather than by size. The straightforward finance-led clients are the ones to move first, partly because they are quick, and partly because moving three or four of them gives you a defensible timeline to offer the clients who are more complicated.
The partners who come out of the next three years well will be the ones who decided early how the work gets delivered, rather than the ones who waited to see how much of it arrived.
Qwyk is a Business Central onboarding and support platform for Microsoft Partners. MSPs, systems accountants and BC consultants use Qwyk to migrate clients from Xero, QuickBooks, Sage and Dynamics GP into Microsoft Dynamics 365 Business Central, automatically, in minutes. Partners choose how involved they want to be, and they always keep the client relationship.
Find out more on our page for BC consultants, our page for MSPs, the Qwyk partner programme, or the partner FAQ.