Dynamics GP migration
Dynamics GP to Business Central migration
Microsoft ends Dynamics GP support on 31 December 2029. A Dynamics GP to Business Central migration moves your data, and it does not move your process. This page covers the dates correctly, what actually transfers, and the question every partner page avoids.
When does Dynamics GP support actually end?
Microsoft ends Dynamics GP support on 31 December 2029, with security updates continuing until 30 April 2031. The date moved from 30 September 2029 in Microsoft's January 2025 lifecycle update, so that customers could close a full fiscal year rather than cut over mid quarter.
It is worth being precise, because the published guidance is inconsistent. Some pages still carry 30 September 2029. At least one states that GP support ends in April 2026, which appears to confuse the end of new licence sales with the end of support. Others describe mainstream and extended support as separate dates in a way that does not match Microsoft's own documentation for this product.
The three month shift matters more than it sounds. A finance team cutting over on 1 January starts a clean fiscal year in one system. A team cutting over on 1 October runs two general ledgers through a quarter end and a year end simultaneously, which is where reconciliation projects go wrong.
What the deadline does not tell you is where to go, how much it should cost, or whether the project needs to be the size you have been quoted. Those are the rest of this page.
What actually migrates, and what does not?
Microsoft's tool moves the chart of accounts, customer, vendor and item masters, open transactions, and a chosen number of years of history. Customisations are rebuilt or dropped. The spreadsheets around GP migrate to nothing at all, and they are where your process lives.
| What | Does it migrate | What to know |
|---|---|---|
| Chart of accounts | Moves | Standard in Microsoft's migration tool. |
| Customer and vendor masters | Moves | Usually clean, though duplicates surface that nobody knew about. |
| Item masters | Moves | Expect to spend time on units of measure and item categories. |
| Open transactions | Moves | Open receivables, payables and orders at cutover. |
| Historical transactions | Partly, by choice | Three to five years is the common decision. More costs time and buys little. |
| Historical inventory detail | Usually archived, not migrated | Kept readable in GP or exported, rather than carried across. |
| Customisations | Rebuilt or dropped | This is the expensive column, and it is where estimates diverge most. |
| The spreadsheets around GP | Nothing migrates them | They hold the process. No tool touches them and few quotes mention them. |
The last row is the whole argument of this page, and it is missing from every guide we read while researching it.
In almost every GP installation of this age there are workbooks doing real work. A production schedule a planner rebuilds weekly. A pricing matrix for contract customers that the standard price list cannot express. A quality certificate someone assembles by hand because no system produces it in the format one large customer demands. A commission calculation. A cash forecast.
None of that is in GP, so none of it appears in a data migration scope. All of it is load bearing. The business runs on it, and on 2 January it still has to.
There is a reasonable objection to raising this: it is not the migration partner's job. That is correct. Their scope is the ERP, they quote the ERP, and they deliver the ERP. The problem is not that anyone is being unhelpful, it is that nobody owns the gap, and a gap nobody owns gets discovered rather than planned.
The fix costs nothing and takes a fortnight. List the workbooks before you accept any quote. For each one, note what it produces, who maintains it, roughly how long it takes each week, and what in GP it reads from. That list tells you which ones become straightforward reports in the new system, which need rebuilding as proper tools, and which can simply stop existing because the thing they worked around is gone.
This is the difference between a migration that completes and a business that works. The first is measured by whether the balances tie. The second is measured by whether anyone can do their job on Monday.
Why do your GP customisations matter so much?
Because each one exists for a reason, and that reason rarely disappears. A GP customisation was written because standard GP could not do something your business needs. Business Central is a different product, not a newer GP, and frequently cannot do that thing either.
Published estimates suggest a large proportion of customisations need rebuilding rather than carrying across, and the range quoted is wide enough that it should be treated as a signal rather than a number: the honest answer is that nobody knows until someone looks at yours.
The useful exercise is not counting them. It is asking, for each one, what problem it solved. Three answers are common.
It solved a problem Business Central solves natively. Good outcome. The customisation disappears and you gain supportability. Some genuinely do.
It solved a problem that no longer exists. Also good. Businesses change and some customisations are archaeology. Removing them is the cheapest win in the project.
It solved a problem that is still real and still unsupported. This is the common case and the expensive one. The function has to exist somewhere after cutover: as a Business Central extension, as a separate tool, or as another spreadsheet. Pretending otherwise does not make the requirement go away, it just moves the discovery to the week after go live.
Sorting your customisations into those three buckets costs a few days and changes the shape of every quote you receive.
What does a GP to Business Central migration cost?
Published estimates vary by roughly five times, from around fifty thousand dollars to several hundred thousand for the same described scope. That spread is not vendors disagreeing. It reflects how differently two GP installations of the same size can be customised and integrated.
| What moves the number | Why | What to do about it |
|---|---|---|
| How many customisations GP has | Each one needs a decision: rebuild, replace with standard, or drop | The single largest variable. Published figures suggest a large share need rebuilding rather than carrying across. |
| How clean the data is | Duplicate vendors, dead items, accounts nobody uses | Cheap to fix before migrating, expensive to discover during. |
| How many systems integrate with GP | Each integration is its own small project with its own testing | Frequently underscoped because nobody has the full list. |
| How much history you carry | Three years against ten changes effort and cost materially | Decide early. It is a business decision, not a technical one. |
| Whether the spreadsheets get addressed | Ignored at quoting, discovered at go live | The gap between a migration that works and a business that works. |
We have deliberately not published our own range. A figure quoted before anyone has listed your customisations and integrations is a guess, and adding another guess to a field that already disagrees with itself by a factor of five helps nobody.
What does transfer between projects is which questions change the answer. If you can tell a partner how many customisations you have, how many systems talk to GP, how many years of history you want and how clean your vendor master is, the quote you get back will be far closer to the final number. All four of those you can establish yourself.
One line that is almost never quoted: your own people. The controller and the person who knows how GP is actually used will both lose significant time to this project, and they are the people the business can least spare. Budget it honestly or the timeline slips waiting for them.
What does the project actually look like?
Six phases, and partners quote the fourth. Inventory, decide the destination, cleanse the data, configure and migrate, run in parallel, then close the gaps the ERP still does not cover. The first and last are where projects are won and lost.
| Phase | What happens | What to know |
|---|---|---|
| Inventory, before anything | Every export, report, integration and spreadsheet attached to GP, and who maintains each | You can do this yourself, free, and it makes every quote you receive more accurate. |
| Decide the destination | Business Central, something else, or staying put for now | Worth asking properly, because the people quoting cannot ask it for you. |
| Data cleanse | Duplicates, dead records, account structure | Before migration, not during. Far cheaper and it de-risks the cutover. |
| Configure and migrate | The part the partner performs | Commonly two to six months depending on complexity. This is the phase everyone quotes. |
| Parallel run | Both systems, same transactions, reconciled | Two to four weeks is typical. It is the first thing cut when a date tightens and the last thing that should go. |
| The gap work | The spreadsheets and processes the ERP still does not cover | Nobody budgets for this and everybody ends up doing it. |
Published timelines for the fourth phase range from about six weeks to twelve months, which again reflects how different two installations can be rather than disagreement about method. Two to six months covers most mid sized migrations without unusual complexity.
The parallel run deserves defending. For two to four weeks both systems process the same transactions and somebody reconciles them. It is tedious, it is the first thing cut when a date tightens, and it is where you discover that a calculation has been quietly wrong for years, or that a report nobody mentioned is load bearing. Protect it.
The sixth phase is the one that appears in no proposal. After go live the spreadsheets are still there, and now they are pointing at a system that structures its data differently. Somebody has to rebuild them or replace them. Budgeting for that in advance turns a nasty surprise into a planned piece of work.
Should you move to Business Central at all?
Usually yes if you are on GP and intend to stay with Microsoft, because it is the supported path and the migration tooling exists. But it is a fair question to ask properly, and every page ranking for this search is published by a partner who is paid to answer it one way.
We are not a Dynamics partner. We do not sell, resell or implement any ERP and we take no referral fees from anyone who does. That gives us no reason to prefer a destination, and it is the reason to weigh what follows.
Business Central is the obvious path and for most GP users it is the right one. Familiar Microsoft shape, direct migration tooling, a large partner community, and a product with a future.
It is not automatically right for process manufacturers. If you mix, batch and measure rather than assemble, test that carefully. Discrete assumptions run through a lot of products and the mismatch is expensive to discover late.
It is not right if the real problem was never the ledger. Plenty of GP installations work fine as a system of record, and the pain is entirely in the eleven spreadsheets around it. Migrating the ledger moves the spreadsheets to a new ERP and changes nothing about them. That is worth knowing before spending six figures.
Staying put has a date on it. Security updates end on 30 April 2031. That is a real horizon, not an indefinite one, and planning to run unsupported financial software past it is a decision rather than an absence of one.
What do you actually gain by moving?
Support, first and above everything else. After that: browser and mobile access without remote desktop, a documented API instead of eConnect and direct SQL, reporting that does not need a specialist, and two feature releases a year. The API change matters more than it sounds.
| What you gain | What it means | Honest assessment |
|---|---|---|
| It is supported | Regulatory and tax updates keep arriving after 2029 | The honest headline reason. Most of the others are secondary to this one. |
| Browser and mobile access | No Citrix, no remote desktop to reach the ERP | Genuinely useful for anyone outside the office, and a real change for field and sales staff. |
| Modern integration surface | A documented API rather than eConnect and direct SQL | Matters more than it sounds. It decides how expensive every future connection is. |
| Power BI and reporting | Reporting that does not require a GP specialist | Worth testing with your own month end pack before believing any demonstration. |
| Regular updates | Two major releases a year, applied automatically | A benefit and a cost. Extensions have to keep up, which changes how you maintain customisations. |
The third row is the one worth understanding, because it changes the economics of everything you build afterwards. Connecting anything to GP generally meant eConnect, integration tools, or writing directly against the SQL database and hoping a service pack did not move something. Each connection was a small bespoke project with its own fragility.
A documented API changes that. The shop floor terminal, the customer portal, the scheduling tool, the quality certificate generator: each becomes a normal integration rather than an exercise in archaeology. If your plan includes any of those, that gain is worth more over five years than the feature differences anyone will demonstrate.
The last row is a genuine trade rather than a pure benefit. Two releases a year keeps the product current and means extensions must be maintained to match. That is manageable and it is not free, and a vendor who presents it purely as an advantage is not describing your maintenance year accurately.
What goes wrong in a GP migration?
Five things, and four of them are discovered rather than predicted. Unlisted integrations, dirty master data, posting and valuation differences, reports nobody mentioned, and a parallel run that got compressed because the date slipped.
| What goes wrong | What it looks like | When you find out |
|---|---|---|
| Nobody listed the integrations | The EDI feed, the shipping system, the customer portal, the Access database in accounts | Cutover week, when something stops working and nobody knew it existed. |
| Dirty master data | Four spellings of the same vendor, items nobody has sold since 2015 | During migration, when it becomes an expensive problem rather than a cheap one. |
| Posting and valuation differences | Inventory valuation and posting behaviour are not identical between the products | At the first month end, when numbers do not match what finance expected. |
| Reports nobody mentioned | A spreadsheet one director has received monthly for nine years | The first month it does not arrive. |
| The parallel run got cut | Two to four weeks compressed into a weekend because the date slipped | Immediately, and in the worst possible way. |
The first row is the most common and the most preventable. A GP installation of fifteen years has accumulated connections nobody holds a list of. The EDI feed to one large customer. The shipping system. A portal built by a contractor who left. An Access database in accounts that reads straight from the SQL tables and that nobody has thought about since 2018.
Each one is small. Discovering it during cutover week is not, because cutover week has no spare capacity by design. This is precisely why the inventory matters more than any other preparation you can do.
The third row catches finance teams specifically. Inventory valuation and some posting behaviours do not work identically across the two products, and the first month end after go live is where that surfaces. Ask about it explicitly during scoping, with your own valuation method named, rather than discovering it in a variance nobody can explain.
How do you read a migration quote?
Compare what is excluded, not what is included. Every partner quote covers configuration and data migration. The differences that decide your final cost are data cleansing, integration work, post go live support and the parallel run, and those are where quotes diverge quietly.
| Ask every partner | What the answer tells you |
|---|---|
| What is not included in this price? | A good answer names data cleansing, integrations and post go live support explicitly. A vague answer is the single most reliable warning sign. |
| How many of our customisations have you seen before? | Specifics beat reassurance. Ask which ones they expect to be standard in Business Central and which will need building. |
| Who exactly will be on this, and in month five? | Many firms sell with senior people and deliver with whoever is free. Ask for names and their other commitments. |
| What does the parallel run look like? | Length, who reconciles, and what happens if the numbers do not tie. If they cannot answer, they have not planned one. |
| What happens to our spreadsheets? | Most will say that is outside scope, which is honest and correct. The point is to hear it now rather than in January. |
There is a structural point worth naming, and it applies to everyone quoting including anyone you find through this search. A partner is paid to perform a migration. That does not make them dishonest, and most Dynamics partners are competent people doing careful work. It does mean nobody in that conversation is incentivised to ask whether the project could be smaller, or whether the ledger was ever the real problem.
The defence is not suspicion, it is specificity. A partner handed a complete inventory of your integrations, customisations and spreadsheets will quote far more accurately than one working from a user count, and the quotes become comparable to each other. Vagueness in your brief becomes padding in their price, and neither of you benefits.
The last question in that table is the one to listen hardest to. Most partners will say the spreadsheets are outside their scope, which is both honest and correct. The point of asking is to establish, before you sign, that somebody still has to deal with them and that it is not going to be the person you just paid.
How long should you leave before the deadline?
Start the inventory now and the project by early 2028. Support ends 31 December 2029 and security updates in April 2031, but partner capacity is finite and thousands of GP customers share the same deadline. The last year will be the most expensive and the least available.
The arithmetic is straightforward. A mid sized migration runs two to six months of partner work, plus data cleansing before it and a parallel run after. Add the decision time that any six figure purchase takes in a business this size and a comfortable programme is twelve to eighteen months end to end.
Working back from 31 December 2029, that means starting in 2028 to cut over with a margin. Working back from 30 April 2031, the absolute horizon, you have more room, though running unsupported financial software through a year end is a decision most finance directors would rather not defend.
One further timing note that catches people out. Most businesses want to cut over at a period end, ideally a year end, which means the usable cutover windows are far fewer than the calendar suggests. If your financial year ends in December and you want a clean start, you are choosing between a small number of specific weekends across the whole programme, and every other GP customer with a December year end is choosing from the same set.
The capacity point is the one people underestimate. Every GP customer faces the same date. Partner implementation teams do not expand to match, and the firms worth hiring will be booked furthest ahead. Prices tend to firm up and timelines lengthen as a deadline of this kind approaches.
None of which is a reason to rush into a decision this week. It is a reason to do the free part now. The inventory costs you two weeks of part time attention, commits you to nothing, and leaves you able to move quickly when you do decide.
What should you clean up before migrating?
Five things, all of which are cheaper to fix in GP than to discover in Business Central: duplicate customers and vendors, dead items, unused accounts, inconsistent units of measure, and open transactions that are not actually open. None of this needs a partner.
| What to clean | What it looks like | Why now rather than later |
|---|---|---|
| Duplicate customers and vendors | Same company under three spellings, each with its own history | Merge before migrating. Afterwards the history is split across records and merging is far harder. |
| Dead items | Parts not sold or bought in several years | Deactivate rather than delete, so history stays readable, and keep them out of the new item master. |
| Unused accounts | A chart of accounts that grew by accretion and nobody pruned | The best chance you will get to restructure. Changing it later is painful. |
| Inconsistent units of measure | Each, EA, PCS and pieces all meaning the same thing | Cheap to standardise now, and it affects every transaction afterwards. |
| Open transactions that are not open | Orders from 2019 nobody closed, credits never applied | Clear them, or they migrate and sit in the new system looking live. |
This is the most reliably underestimated work in a Dynamics GP to Business Central migration, and also the part most fully within your own control. It needs no licence, no partner and no decision about destination. It can start the week you begin thinking about the project and it reduces the price of every quote you later receive.
The third row deserves particular attention because the window closes. Migration is the one natural opportunity to restructure a chart of accounts that has grown by accretion for fifteen years, with accounts added for one off reasons that nobody remembers. Restructuring afterwards means re-mapping history and re-cutting every report built on it, so it tends not to happen. Decide what the chart should look like now, while the cost is a conversation rather than a project.
The last row causes a specific and avoidable embarrassment. Old orders and unapplied credits migrate across looking perfectly live, and then appear in the first aged report somebody runs in the new system. Finance quite reasonably concludes the migration went wrong, when in fact the data was like that all along and nobody had looked.
A fortnight of somebody competent working through master data is one of the highest return activities available in this entire project, and it has the unusual property of being useful even if you ultimately decide not to migrate at all. A cleaner vendor list and an honest item master make the existing system better too.
Where does Voliom fit in this?
Not in the migration itself. We do not perform ERP migrations and would not quote for one. We build the layer around the ERP: the integrations, and the tools that replace the spreadsheets no migration touches. Often that is the work still outstanding after a partner has finished.
Before the migration, the inventory. Documenting every export, report, integration and spreadsheet attached to GP, with who maintains each and roughly what it costs in hours. You can do this without us, and it makes every partner quote more accurate. Where we do it, the output is a document you own and can hand to whoever you choose.
During, the integrations. The systems that talked to GP need to talk to Business Central, and the mapping is rarely one to one. This is the work that quietly expands if nobody listed the integrations at the start.
After, the gap. The scheduling workbook, the contract pricing matrix, the customer specific certificate. These were built because GP could not do them, and in most cases Business Central cannot either. Building them properly, connected to the new system, is what we actually do.
If you are mid way through choosing a partner, we are not competing for that work and are happy to look at a scope you have been given and say what we think is missing from it. That costs you nothing and we are not going to end up bidding against the person who wrote it.
What should you do first, this month?
Write the inventory. Every spreadsheet, export, report and integration attached to GP, who maintains it, and roughly how long it takes each week. It costs nothing, you can do it internally, and it is the single thing that makes every subsequent conversation shorter and cheaper.
That document does four jobs at once. It tells you how large the project really is before anyone quotes. It gives every partner the same concrete scope, so the quotes become comparable. It becomes the migration checklist. And the hours column tells you which of those spreadsheets is worth replacing properly rather than rebuilding against the new system.
Two weeks of part time attention is enough. Ask the controller, the planner, whoever produces the month end pack, and whoever deals with the customer portals. The question is simply: what do you open, what do you copy, into what, and how long does it take.
The surprises are consistent. The workbook costing the most is rarely the one people complain about. And there is almost always at least one integration nobody remembered until someone asked, which would have been discovered during the cutover instead.
Then, if you want, send us the list. We will tell you which items are integration work, which need rebuilding, and which can simply stop existing. No charge, and no onward sale of a migration, because we do not do them.
FAQ
Common questions
When does Dynamics GP support end?
Microsoft ends Dynamics GP support on 31 December 2029, with security updates continuing until 30 April 2031. The date moved from 30 September 2029 in Microsoft's January 2025 lifecycle update so customers could close a full fiscal year. Several published guides still print the older date.
What data migrates from GP to Business Central?
Microsoft's migration tool moves the chart of accounts, customer, vendor and item masters, open transactions and a chosen number of years of history, commonly three to five. Historical inventory detail is usually archived rather than migrated. Customisations are rebuilt or dropped, and the spreadsheets around GP migrate to nothing.
How long does a GP to Business Central migration take?
Published estimates run from about six weeks to twelve months. Two to six months covers most mid sized migrations without unusual complexity. The variable is rarely the data migration itself; it is the number of customisations and integrations, and how long decisions take about which ones to rebuild.
How much does migrating from GP to Business Central cost?
Published estimates vary by roughly five times for the same described scope, which reflects how differently two GP installations can be customised. Rather than add another figure, establish your own drivers first: how many customisations, how many integrations, how many years of history, and how clean the vendor and item masters are.
Do our GP customisations transfer to Business Central?
No. They are rebuilt as extensions, replaced by standard functionality, or dropped. The useful exercise is asking what problem each one solved. Some are solved natively in Business Central, some solved problems that no longer exist, and some solved problems that are still real and still unsupported, which is the expensive case.
What happens to the spreadsheets around GP?
Nothing migrates them, and they usually hold real process: a production schedule, a contract pricing matrix, a customer specific certificate. They are absent from data migration scopes and still load bearing on the Monday after go live. Inventory them before anyone quotes the project.
Is Business Central the right destination from GP?
For most GP users staying with Microsoft, yes, and it has direct migration tooling. Test it carefully if you are a process manufacturer, since discrete assumptions run through many products. And if the real pain was never the ledger but the spreadsheets around it, migrating the ledger will not change that.
Can we stay on Dynamics GP after 2029?
The software will keep running, and security updates continue until 30 April 2031. After that you would be running unsupported financial software with no regulatory or tax updates, which is a decision to take deliberately rather than by default. Most businesses treat April 2031 as the real horizon.
Does Voliom perform GP migrations?
No. We do not sell, resell or implement any ERP and take no referral fees from partners who do. We build the integrations and the tools that replace the spreadsheets a migration does not touch, which is usually the work still outstanding once a partner has finished.
Keep exploring
Related
- Manufacturing software guideWho writes the rankings, and why
- Systems integrationWhat has to talk to the new ERP
- Application modernizationWhen the system itself is the problem
- Production scheduling softwareThe spreadsheet that does not migrate
Let's talk
Tell us what you're building.
Get a free 30-minute strategy call. You'll leave with a clear plan, a realistic estimate and our honest opinion, whether or not you work with us.
- Email usmail@voliom.com