Migrating from Dynamics GP to Dynamics 365 Business Central

Dynamics 365 Business Central is where Microsoft points every departing GP customer, and it says so in writing. Microsoft’s own lifecycle documentation for Dynamics GP states plainly that it is encouraging customers to transition to Dynamics 365 Business Central.1 That is a sourced fact about Microsoft’s stated direction, not a sales pitch we are constructing on its behalf. For a large share of GP shops, following that direction is genuinely the right call. But “the vendor’s own designated successor” and “the correct choice for your company” are two different questions, and this guide keeps them separate on purpose. BC is a different product built on different bones, not an upgrade, and the fact that Microsoft named it as your path forward does not, by itself, make it the right one for you. The companies whose BC projects go well are the ones that understood the difference between those two questions on day one.

Why Microsoft points here, and why that is not the whole answer

The 50,000-plus figure is worth sitting with. It was announced by Microsoft at its own Directions EMEA 2025 partner conference, reported by independent Dynamics trade press, and it explicitly excludes everyone still running Business Central on premises, NAV, GP, or Solomon.2 That is 50,000 organizations that have already made the jump into the cloud version specifically, up from a figure north of 45,000 cited at Microsoft’s North American conference only months earlier in the same year.2 Read plainly, that is real momentum behind Microsoft’s chosen successor product, not a marketing footnote.

None of that changes the shape of the decision in front of you. A vendor conference milestone tells you BC is a viable, well-invested, actively growing product. It does not tell you whether your payroll dependency, your reliance on direct database queries, or your headcount trajectory make BC the right fit. Microsoft has an obvious interest in every GP customer landing on a Microsoft product, and Business Central is the only Microsoft product built to receive them. That interest is not dishonest, and it does not make the recommendation wrong. It does mean the recommendation deserves the same scrutiny you would give any vendor telling you where to spend the next seven figures of software budget over a decade.

Who Business Central fits, and who it does not

BC fits GP shops that want to stay inside the Microsoft ecosystem. If your company runs on Microsoft 365, your IT team already thinks in Azure and Active Directory, and your users live in Outlook, Excel, and Teams, BC slots into that world natively: single sign-on, Excel editing of journal data, embedded Power BI, Power Automate flows against ERP data. That integration story is BC’s strongest card, and no direct competitor matches it, because no competitor is built by the same company that builds your identity platform, your productivity suite, and your cloud infrastructure.

It also fits the classic GP profile: a products or services company from roughly 10 to a few hundred employees that needs solid financials, distribution, and light manufacturing without a tier-one ERP budget. That is precisely the mid-market segment GP itself was built for, and BC was designed as its cloud-native continuation.

BC fits less well when payroll is central to why you run GP in the first place. It has no native US or Canadian payroll, so you will move payroll to an ISV or a service like ADP or Ceridian. For some GP shops that single change, not the accounting migration, is the biggest part of the project.

It also fits less well if you depend on deep Dexterity customization that encodes decades of process. All of it gets rebuilt or rethought in BC’s AL extension language. If GP is effectively a custom system wearing a GP badge, evaluate honestly whether BC, another suite such as Odoo, or purpose-built software best fits what you actually built, rather than assuming the Microsoft label carries the customization forward. And it fits less well for teams that have concluded, watching GP’s own wind-down play out, that they would rather not stake the next decade on one vendor’s roadmap a second time. That is a legitimate, common reaction, and it is exactly the reasoning behind our separate Dynamics GP to Odoo guide, which walks through an open-source alternative with a different cost and control model.

What actually changes

The word “Dynamics” on both boxes hides how much moves under your feet.

Three of these deserve emphasis, and one of them is the tradeoff most GP shops underweight until it bites them.

Chart of accounts and dimensions. GP encodes analysis into the account string itself, so a company that wants to slice results by department, location, and project ends up with account numbers like 100-4100-01-500 that only make sense to whoever built them. BC keeps accounts short and attaches dimensions, such as department, project, and location, to each transaction instead. This is a better model for most companies, and migration is the one honest chance you get to fix a chart of accounts that grew organically for twenty years. Do not replicate your GP segments in BC one for one; doing so just imports your technical debt into a new system with a nicer interface.

Reporting. Management Reporter, or FRx before it, does not exist in BC’s world. Every financial statement your controller relies on gets rebuilt in BC’s financial reporting module, in Excel layouts, or in Power BI. Every SmartList people actually check each morning needs a working equivalent on day one, not a promise to build it later. Inventory the reports people actually use, which is usually far fewer than the reports that technically exist in GP, before you let anyone scope hours for this part of the project.

Direct SQL access. This is the one that surprises companies mid-project. Many GP shops quietly depend on direct database reads: a controller’s Excel workbook pulling live balances through an ODBC connection, a warehouse job querying inventory tables nightly, a homegrown dashboard hitting GL00100 or RM00101 directly because someone built it in an afternoon a decade ago and it has run ever since. Business Central online closes that door entirely. There is no equivalent connection string to swap in. Every one of those dependencies becomes its own small migration project: rebuilt against BC’s REST APIs, an OData feed, or Power BI’s native connector, each with its own testing and its own risk of quietly breaking a report nobody remembered depended on the old query until it stopped working.

The market Microsoft is asking you to join

Part of the case for BC is not about BC specifically, it is about where the rest of the market has already gone. Among organizations that replaced their ERP system in 2024, 70.9 percent chose a true multi-tenant SaaS deployment rather than a hosted or managed-services model, up from only 52 percent choosing SaaS the year before.4 That is not a preference for cloud in the abstract; it is a specific swing toward the deployment model BC uses and GP never had, since GP has no true SaaS version of its own.

This is a useful reality check, not a verdict. It tells you that if you are going to run a modern ERP at all, SaaS is where nearly everyone comparable to you has landed, and BC is a legitimate representative of that model. It does not tell you that BC in particular, versus another SaaS-native option, is the correct SaaS to land on. The direction of the market and the identity of your specific vendor are two different arguments, and it is easy to let a true statement about the first quietly stand in for the second.

The per-seat cost curve

GP’s licensing, for most existing customers, was a perpetual purchase plus an annual maintenance percentage: a cost that grew slowly and predictably regardless of how many people used the system day to day. BC inverts that. Licensing is per user per month, and following a price increase effective November 1, 2025, Microsoft’s list pricing is 80 dollars per user per month for Essentials, 110 dollars for Premium, and 8 dollars for the lighter Team Member tier aimed at occasional users who only need to view data or submit a timesheet or expense report.3 Those are list figures; actual street pricing varies through Microsoft partners and CSPs, so treat them as the ceiling you negotiate down from, not the number you will necessarily pay.

The mechanics matter more than the sticker price. A 15-person GP shop moving to BC Essentials is looking at roughly 1,200 dollars a month, a manageable and fairly predictable line item that most controllers can absorb without much drama. A 150-person company on the same tier is looking at roughly 12,000 dollars a month, and unlike GP’s maintenance fee, that number rises automatically every time you add a role that needs full ERP access, with no equivalent ceiling.

None of this makes BC a bad deal. Plenty of companies get more value out of BC than the license costs, especially once you count what they are no longer paying for on-premises infrastructure and version-upgrade projects. But it does mean the cost comparison against GP is structurally different, not just a different number for the same kind of bill, and it is exactly the kind of comparison worth running against alternative licensing models, including Odoo’s, before you sign a multi-year commitment. Our Dynamics GP to Odoo guide walks through that different cost structure in detail.

How the migration actually runs

At a high level, a competent GP to BC project looks like this:

1. Inventory. Catalogue companies, modules, Dexterity and Modifier customizations, Integration Manager and eConnect jobs, ISV add-ons, reports, and every integration, formal or informal, including the Excel workbooks with a live SQL connection nobody remembers setting up. This is a week or two of work that determines everything else, and it is the step most likely to be rushed.
2. Design. A new chart of accounts and dimension structure, a decision on each customization (rebuild, replace with a standard BC feature, or drop), ISV re-selection, and a deliberate data-history policy: how much posted history actually needs to live in BC versus a read-only GP archive.
3. Data migration. Master records, meaning customers, vendors, items, and accounts, along with open transactions, come across cleanly, and Microsoft’s cloud migration tool helps for supported GP versions. Clean up before you move: post or delete unposted batches, resolve stale open transactions sitting in tables like RM20101 or PM20000, and deduplicate masters that have drifted over the years. Decide up front how much history to convert versus keep in a read-only archive rather than defaulting to “everything,” which is the choice that multiplies cost, testing, and risk for data most systems handle awkwardly anyway.
4. Rebuild and integrate. AL extensions replacing Dexterity customizations, ISV apps sourced from Microsoft AppSource, new integrations built over BC’s REST APIs, and every rebuilt report tested against the same period-end numbers GP produced.
5. Parallel testing and cutover. Run at least one full close in both systems, reconcile to the penny, train users on real data rather than a sandbox with sample records, then cut over at a month or quarter boundary.

Multi-company GP environments migrate company by company or all at once; the right answer depends on intercompany transaction volume and how much master data is shared across entities, and it is a design decision made deliberately, not an afterthought discovered mid-project.

Just because Microsoft points here does not make it right

It is worth saying plainly, because it is easy to lose track of in a project this large: the fact that Microsoft’s own lifecycle page names Business Central as your recommended path is a real, documented fact.1 It is also, on its own, a weak reason to choose it. Vendors recommend their own products. That is not a scandal, it is how vendors work, and it does not mean the recommendation is wrong for you specifically. It means the recommendation is not evidence, on its own, of fit. The evidence is everything in this guide before this paragraph: whether Microsoft 365 is already how your company operates, whether payroll or heavy customization sit at the center of what GP does for you, whether per-seat cost at your headcount is a rounding error or a real budget line, and whether losing direct SQL access breaks something quietly load-bearing that nobody has documented.

The honest tradeoffs

For BC: the Microsoft integration story is real and unmatched by any competitor, the partner and ISV ecosystem is large and actively growing past 50,000 cloud customers,2 updates arrive continuously rather than as painful version upgrades, and Microsoft’s own investment in SMB ERP now flows through this product specifically.

Against BC: it is a reimplementation dressed in familiar branding, so teams under-budget it expecting an upgrade; payroll is not native; cloud BC removes direct SQL access many GP shops quietly rely on; and per-seat licensing at 80 to 110 dollars a month means your bill compounds with every hire in a way GP’s flat maintenance fee never did.

The fair conclusion: BC is the default destination for GP customers, and defaults earn that status for real reasons, not by accident. Price and plan it as a new ERP implementation, not an upgrade, because the moment you treat it as one is the moment the project starts going sideways. And before you sign, make sure you chose BC because it fits your Microsoft 365 footprint, your headcount plan, and your data access needs, not because it was the name on the page Microsoft pointed to.