Last updated: October 5, 2026
By ZapAI Team
TL;DR: Dynamics GP support ends December 31, 2029, and security updates stop April 30, 2031. Microsoft’s cloud migration tool moves GP master data, open receivables and payables, open purchase orders, inventory, and summarized GL history into Business Central. It doesn’t rebuild your custom reports, Dexterity add-ons, or integrations. Plan four to nine months, clean data first, and treat segments-to-dimensions as the real design decision.
To migrate Dynamics GP to Business Central, clean your GP data, map account segments to dimensions, run Microsoft’s cloud migration tool for master data and open transactions, rebuild reports and integrations, then test a parallel month-end before go-live.
Most GP customers aren’t asking whether to move anymore. They’re asking how to move without wrecking a month-end close. Fair question. GP has run some of these finance teams for 20 years, and the people who built its custom reports, wrote its Dexterity tweaks, and remember why the chart of accounts has four segments instead of two have often left the company long ago.
The deadline is real. Microsoft’s end-of-support announcement set December 31, 2029 as the end of product enhancements, tax updates, and technical support, with security patches continuing until April 30, 2031. New GP subscriptions stopped selling on April 1, 2026, per Microsoft’s migration options update. Payroll and 1099 tax tables are usually what forces the timing. Nobody wants to file year-end on unsupported tax logic.
This guide is the practical Dynamics GP to Business Central migration plan we’d hand a controller on day one. What moves automatically, what doesn’t, and where these projects actually stall.
What Does Microsoft’s Migration Tool Actually Move?
Master records, open receivables and payables, open purchase orders, inventory with lot and serial numbers, checkbooks, and summarized GL balances by fiscal period. Detailed history can come across as a read-only snapshot.
Under the hood, the cloud migration tool is a set of Business Central extensions that replicate your GP SQL data into Business Central online through Azure Data Factory, then upgrade it into Business Central tables. Microsoft’s GP migration documentation spells out exactly what comes across. Here’s the condensed version.
| GP data | What the tool does | Watch out for |
|---|---|---|
| Chart of accounts | Main segment becomes the account. Other segments become dimensions. | Only two global dimensions. The rest become shortcut dimensions 3 to 8. |
| GL history | Summary transactions per fiscal period for open and chosen historical years | Not transaction-level detail in the ledger itself |
| Customers and receivables | All or active customers, addresses, and open transactions at remaining balance | A $1,000 invoice with $400 paid arrives as a $600 open invoice |
| Vendors and payables | All or active vendors, EFT bank info, open transactions, 1099 data from 2024 onward | Undeposited receipts don’t migrate. Deposit them first. |
| Purchase orders | Open quantities only | Fully received and invoiced lines are skipped |
| Inventory | Items, locations, quantities, lot and serial numbers, valuation method | GP unit-of-measure schedules have no direct equivalent |
| Detailed history | Optional GP Historical Snapshot tables, read-only | Viewable and reportable, not editable or re-postable |
That snapshot option is underrated. It parks GL detail, sales, purchasing, and inventory history in extension tables that Power BI can read, so you don’t need to drag 15 years of transactions into the live ledger, where they’d slow down every report and complicate every audit question about which system holds the official record. Most companies don’t. They shouldn’t. Keep the ledger lean.

What Doesn’t Migrate Automatically?
Custom reports, Management Reporter layouts, SmartList favorites, Dexterity customizations, third-party GP add-ons, integrations, workflows, and security roles. Each needs a Business Central equivalent, rebuilt or replaced.
This list is where budgets go. Every modified invoice form built in GP Report Writer or SQL Server Reporting Services gets rebuilt as a Business Central report layout. Management Reporter statements get recreated in Business Central’s Financial Reporting feature, which uses row and column definitions instead of MR’s building blocks. Different tool. Same balance sheet, eventually.
Third-party products are the sneakiest line. A typical mid-sized GP install has a handful of ISV add-ons for things like sales tax, EFT, document management, or fixed asset depreciation tweaks. Some vendors ship Business Central versions on AppSource. Some don’t. Inventory every add-on in week one and assign each a fate, because the add-on nobody listed is always the one that turns out to calculate sales tax for three states or feed the bank’s positive pay file. Replace. Rebuild. Retire.
And Dexterity? GP’s old customization language has no path into Business Central. Custom Dexterity screens become AL extensions, Power Apps, or, most often, a process change that makes the customization unnecessary. The consultants who can read Dexterity code are getting harder to find every year, so document what those customizations do now, while someone still remembers.
How Long Does a GP to Business Central Migration Take?
Four to nine months for most mid-market companies. A single-company GP install with clean data and few add-ons can go live in about 12 to 16 weeks. Multiple companies and custom integrations stretch it.
| Scenario | Typical timeline | What drives it |
|---|---|---|
| One company, standard GL, AP, AR, few add-ons | 12–16 weeks | Data cleanup and report rebuilds |
| 2 to 5 companies, inventory, a few integrations | 4–7 months | Dimension design, intercompany, integration rebuilds |
| Many companies, payroll, heavy Dexterity customization | 7–12 months | Replacing custom logic, payroll provider change, testing |
Payroll deserves its own line. Business Central doesn’t include US payroll, so GP payroll customers move to a payroll provider or an AppSource payroll app at the same time, which turns one migration into two coordinated migrations with two vendors, two test plans, and one very nervous HR manager. Doing that mid-year means migrating year-to-date earnings. Most teams avoid it. They switch payroll on January 1.
Step-by-Step Migration Plan
Here’s the sequence we follow. Seven steps, roughly in this order, with some overlap between building and testing.
- Assess and inventory. List companies, modules, add-ons, integrations, reports, and users. Confirm you’re on GP 2015 or later and SQL Server 2016 SP1 or later with compatibility level 130, which the migration prerequisites require.
- Clean the data in GP. Inactivate dead customers, vendors, and items. Deposit open receipts. Close out stale purchase orders. Two to four weeks, done by your team.
- Design dimensions. Decide which segments become global dimensions and whether some segment values should become accounts instead. This is the decision you’ll live with for a decade.
- Run a test migration. Set up the extensions, replicate into a sandbox, and compare trial balances, aged receivables, and aged payables against GP to the penny.
- Rebuild what doesn’t move. Reports, financial statements, integrations, approval workflows, and permission sets.
- Test a parallel close. Run one real month in both systems. Every variance gets explained before anyone signs off.
- Cut over. Final replication after a period close, go-live, then decommission GP once the first Business Central close is clean.
Step three is where we spend the most senior time. Why? GP charts of accounts with department and division segments often explode into thousands of accounts, because every combination of main account, department, and division had to exist as its own record before anyone could post to it. Business Central’s dimensions collapse that back to a short account list with tagged values, which makes reporting far easier. But it’s a redesign, not a mapping exercise.

Should You Lift and Shift, or Redesign?
Redesign the chart of accounts and reporting, lift and shift the open transactions. Moving GP’s structure one-to-one keeps old pain. Rebuilding everything from scratch costs months you probably don’t have.
There’s a tempting middle path we steer people away from. Some teams decide to migrate as-is now and clean up later. Later rarely comes. Once the Business Central go-live is behind them, nobody wants to restate dimension history mid-year. If the chart of accounts is wrong, fix it during the migration, when every report is being rebuilt anyway.
Its opposite is rarer. And pricier. A finance team decides to redesign every process at once, including approvals, budgeting, and project accounting. Scope doubles. Pick the two or three processes that hurt most and change those. Leave the rest for phase two.
Is Business Central Right for Every GP Customer?
For most, yes. Very large GP customers with complex manufacturing or many international entities sometimes fit Dynamics 365 Finance better. Some evaluate NetSuite or Sage Intacct too.
- GP with one to ten companies, standard distribution or services. Business Central is the natural home and the migration tool exists for exactly this path.
- Heavy discrete manufacturing on GP with third-party MRP. Business Central Premium plus an AppSource manufacturing app often covers it, but test your toughest routing.
- Dozens of international entities? Look at Dynamics 365 Finance, or read our Business Central vs NetSuite comparison for the multi-subsidiary tradeoffs.
- Tiny GP install, three users, bookkeeping only. Business Central Essentials works, and the cost is easy to plan.
Licensing usually stays close to what GP customers pay for their Enhancement Plan. Microsoft has run Bridge to the Cloud promotions that discount Business Central for qualifying on-premises customers, so ask your partner which offer, if any, applies when you sign. Then plan the services budget separately using our Dynamics 365 implementation cost guide.

Where Do GP Migrations Go Wrong?
Dirty data, underestimated report rebuilds, forgotten add-ons, and skipping the parallel close. Almost every troubled migration we’ve reviewed skipped at least one of those four.
Reporting is the quiet one. Finance teams don’t think of their 40 SmartLists and Excel refreshable reports as a project deliverable until the first Monday after go-live, when the AR manager can’t find her aging-by-salesperson view. Catalog reports early. Business Central lists can be filtered, saved, and exported much like SmartLists, and Power BI reporting covers the dashboards GP never did well. But someone has to rebuild each one.
Then there’s timing. Partners experienced in GP migrations are busy, and a single 2029 deadline means thousands of finance teams will try to book the same consultants for the same two or three fiscal year-ends, which is exactly when good partners stop taking new projects. Starting the assessment in 2026 or 2027 gives you a choice of partner and a calm cutover date. Starting in late 2028 gives you neither.
Wrapping Up
GP to Business Central is the best-supported migration path Microsoft offers, and the tool handles the mechanical part well. Your work is the judgment part. Clean the data, redesign the dimensions once, inventory every add-on and report, and prove it with a parallel close.
ZapAI runs GP migrations for mid-market finance teams in the US and India. If you want a written inventory of what will and won’t move from your GP install, our ERP team can run a short assessment against your actual GP database before you commit to a timeline.
Questions GP Customers Ask Us
When does Dynamics GP support actually end?
December 31, 2029 for product enhancements, tax updates, and technical support. Security updates continue until April 30, 2031, after which subscription licenses can’t be renewed. New customers could no longer license GP subscriptions after April 1, 2026.
Can we keep our GP history in Business Central?
Partly. Summary GL balances by fiscal period migrate into the ledger, and detailed GL, sales, purchasing, and inventory history can come across in the read-only GP Historical Snapshot tables. Many companies also keep a read-only GP database for audits.
Does Business Central have payroll like GP?
No US payroll in the base product. GP payroll customers usually move to a payroll provider or an AppSource payroll app, ideally on January 1 so year-to-date earnings don’t need migrating.
Which GP versions can use the migration tool?
GP 2015 and later, running on SQL Server 2016 SP1 or newer with compatibility level 130. Older installs need an upgrade first. Annoying, but usually a short technical step rather than a project.
What happens to Management Reporter?
It doesn’t migrate. Financial statements get rebuilt in Business Central’s Financial Reporting feature using row and column definitions, or in Power BI. Plan a few days per complex statement set, and test every one against GP numbers before cutover, because a balance sheet that’s off by a rounding rule will cost you a week of trust with the CFO.
Do we have to move to the cloud?
Business Central also runs on-premises, but Microsoft’s migration tooling and most new features target Business Central online. Most GP customers move to the cloud version and stop managing SQL servers in the process.
