Dynamics GP retires end of 2029: what actually migrates

If you run finance systems on Microsoft Dynamics GP, the date is now on the board. Microsoft's lifecycle page gives Dynamics GP a retirement date of 1/1/2030 6:59:59 AM Pacific — which, in Microsoft's usual encoding, means the end of December 31, 2029.

That is far enough out to ignore and close enough to plan. This post is about the part that is under-covered: not whether to move, but what Microsoft's own migration tool actually does to your data — and the specific things it leaves behind.

The date, and the detail behind it

Microsoft's Dynamics GP lifecycle page is short. It says GP follows the Modern Lifecycle Policy and gives one row: a start date of 10/7/2019 and a retirement date of 1/1/2030 6:59:59 AM.

Two things are worth pulling out of that.

The encoding. Microsoft writes lifecycle end dates as the following day at 6:59:59 AM Pacific. So the human date is December 31, 2029, not January 1, 2030. This trips people up on every Microsoft lifecycle table, and it is worth getting right in a board paper.

The policy. "Modern Lifecycle" is the one that matters more. Most infrastructure people have a mental model built from products on the Fixed Lifecycle Policy — five years mainstream, five years extended, then a paid ESU bridge if you are desperate. Exchange and Windows Server work that way. Modern Lifecycle has no such structure. There is a retirement date and there is nothing after it. If your plan quietly assumes an extended-support cushion behind 2029, that cushion does not exist.

Microsoft points GP at Business Central. Explicitly.

You do not have to take a partner's word for the destination. The lifecycle page itself links to Dynamics GP data migrated to Business Central online, and Microsoft ships a cloud migration tool with a GP Company Migration Configuration page built for this path.

That is a supported, tooled route rather than an export-and-rekey exercise. It is not the same as saying Business Central is automatically right for your business — an ERP move is a business-process decision before it is a technology one, and "Microsoft's tool goes there" is not a requirements analysis. But it does mean the mechanical part is solved, and that changes where the project risk actually sits.

What the tool does to your chart of accounts

This is the single biggest change and the one most likely to surprise a finance team.

Business Central takes the account number from the main account segment of your GP account. Every other segment becomes a dimension. During setup you nominate which segments become Global Dimension 1 and Global Dimension 2; if your chart carries more than two segments beyond the main one, the remainder are configured automatically as shortcut dimensions 3 through 8.

Microsoft's own worked example: GP account 000-1100-00 becomes Business Central account 1100, carrying dimension values 000 and 00.

Two related details from the same documentation. Historical years arrive open. Years marked historical in GP come across to Business Central as open and must be closed there — which is useful if you need to post an adjustment to a historical year, and a nasty surprise if nobody expects it. And GP unit accounts, which hold non-financial metrics, map to statistical accounts in Business Central and are migrated automatically with their balances.

The four things it does not bring

These are all from Microsoft's own migration documentation, and each one is cheap to handle before the migration and expensive to discover after it.

1. Undeposited cash receipts. Microsoft is explicit that any posted cash receipt should be deposited in GP before migrating, because undeposited receipts are not migrated. This is a pre-migration checklist item, not a configuration option.
2. Fully received and invoiced purchase order lines. Open purchase orders migrate based on items and quantities remaining. An item that is fully received and invoiced is not brought across. That is correct behaviour, but it means the PO history in Business Central is not the PO history in GP.
3. Unit of Measure Schedules. Microsoft states there is no direct equivalent in Business Central to the GP Unit of Measure Schedules table (IV40201) — schedules are a GP construct that groups units of measure, and Business Central stores the units themselves but not the grouping. Business Central does support a base unit plus alternates per item, so the capability exists; the structure does not transfer.
4. 1099 data before 2024. 1099 tax type, Federal ID and box number migrate, along with box amounts — but Microsoft states the first supported year for migrating 1099 information is 2024, and you nominate the calendar year at configuration.

⚠️ One place to read Microsoft's documentation carefully

Outstanding receivables and payables migrate at their remaining amount rather than their original amount, which is the sensible behaviour. But Microsoft's worked example for this contradicts itself, and it appears twice — once under Receivables and again, identically, under Payables.

The example describes a $1,000 invoice that has been partially paid, states that it "has a remaining balance of $400", and then says the invoice created in Business Central is for $600 "because that's the amount remaining to be paid." Both cannot be true. Either $400 remains and the new invoice should be $400, or $400 was paid and $600 remains.

The principle is not in doubt — open transactions come across at what is still owed, not at face value. But if you are validating a test migration against that example, you will not be able to reconcile it. Confirm the behaviour against your own data in a trial run rather than against the documentation's arithmetic. This is a good argument for a pilot company migration regardless.

What you can keep

One genuinely useful feature that gets undersold: the GP Historical Snapshot. At configuration you can elect to bring GP history — GL detail, Receivables, Payables, Sales Order Processing, Purchase Order Receipts and Inventory transactions — into Business Central extension tables, visible under the corresponding entities as GP Detail Snapshot.

Microsoft names those tables (Hist. G/L Account, Hist. Gen. Journal Line, Hist. Payables Document, Hist. Receivables Document, and the Sales, Purchase Receipt and Inventory header/line pairs), and the data is reachable from Power BI, Power Apps and non-Microsoft reporting tools. You can cap the volume with an Oldest Snapshot Year setting, and the snapshot runs as a background process after the migration completes.

In practice that is the answer to "we cannot leave GP because we need the history" — a common and legitimate objection that is usually answered with a promise rather than a named mechanism.

How to sequence this

1. Establish the real deadline. End of December 31, 2029, Modern Lifecycle, no extended phase behind it.
2. Decide the destination on business requirements, not on tooling. Business Central is the documented path; that is an input, not the decision.
3. Design the chart of accounts and dimension model first. This is the project. The migration tool executes a design; it does not produce one.
4. Run a pilot company migration and reconcile it against your own numbers — see the documentation caveat above.
5. Inventory the reporting and integrations written against segmented account strings. That list is your real scope.
6. Handle the pre-migration items: deposit posted cash receipts, decide the oldest historical year, decide the 1099 year, decide the snapshot scope.

We run Dynamics GP to Business Central migrations end to end — the requirements and chart-of-accounts design, the dimension model, the pilot company and its reconciliation, the integration and reporting rebuild, and the cutover itself. Senior-led, fixed-fee, and vendor-neutral: we take no resale margin on Business Central licensing or on any tooling in this post. If the 2029 date is on your board, our Dynamics 365 practice is where that work lives — scope it with us