A GP to Business Central migration is better tooled than most people expect. Microsoft ships a cloud migration capability that replicates your on-premises SQL data table by table, tracks success and failure per table, and lets you rerun it as many times as you need.
That reassurance is worth stating up front, because it is true, and because it is also what causes the trouble. A process you can rerun freely contains three points where you cannot, and none of them announces itself.
What the tool actually is
Worth understanding the shape of it, because it explains both the reliability and the constraints.
Cloud migration is managed from Business Central online through a connection to your on-premises database, with Azure Data Factory doing the actual replication. A self-hosted integration runtime is installed on your network to move data out securely, pipelines orchestrate the copy, and the target is the Azure SQL database behind your Business Central environment.
One line in that description has a consequence people miss. Azure Data Factory does not look at any permissions within the applications it moves data between. It sees only SQL permissions. Your GP security model is not being interpreted, honoured or migrated by the replication itself, which is why security setup is a separate task on the other side rather than something that arrives with the data.
Prerequisites are modest and worth checking early: the on-premises solution must run SQL Server 2016 or later with database compatibility level 130 or higher, and Microsoft supports Dynamics GP 2015 and later. Anything older is not a migration conversation yet.
Replication runs table by table, and failures are captured per table rather than stopping the run. A table fails if it cannot be found or if the schema does not match between on-premises and cloud, and the migration simply moves on to the next one. That is a sensible design and it means the failure list is the artefact to work from, not the completion message.
What comes across
The migrated set is broader than people assume:
- System and company setup, such as payment terms, shipping methods and sites
- Master data for accounts, customers, vendors and items
- Transactional data
- Classes for customers, vendors and items
- Vendor 1099
- Historical data
Which company data migrates is configurable during setup, so this is a scope decision rather than a fixed list. That configurability is worth using. Historical data is the usual candidate for reduction, and reducing it is one of the few levers that shortens a migration window materially.
The first one-way door: the read-only period
The moment cloud migration is configured and running, the Business Central online tenant becomes, in effect, read-only.
Microsoft implements this with a permission set called Intelligent Cloud. Once the migration environment is configured, existing online users who do not hold SUPER permissions are automatically assigned to it, and only SUPER users can modify the system. The logic is sound: anything written to the tenant during migration would be continuously overwritten by the replication.
Three things about that catch teams out.
At least one user per company needs SUPER before you connect. Microsoft says so explicitly, and it needs doing before configuring the connection rather than after.
New users added later are not assigned Intelligent Cloud automatically. You have to assign it yourself, which is exactly the kind of step that gets missed when someone joins mid-project.
Intelligent Cloud grants read access to all data by default. If you need to restrict what a user can read during the migration period, the recommended approach is to copy the Intelligent Cloud permission set and remove permissions from the copy, rather than building something new.
And a warning that reads mildly and is not: if you grant insert, modify or delete permissions on a resource that was set to read-only, it can damage the online data, and you may have to clear all your data and rerun a full migration to correct it. That is a permission change with a full-restart consequence.
The second one-way door: the data upgrade
Replication you can rerun. The data upgrade after it, you cannot.
The sequence is replicate, then run data upgrade, then validate. Microsoft’s instruction is unambiguous: ensure data from all companies has been replicated before running the upgrade, because once the upgrade has run successfully you cannot run data replication again from an earlier version. Doing so risks corrupting the online database by mixing upgraded and non-upgraded records.
So the practical rule is that the upgrade is the commit point. Everything before it is rehearsal, and everything after it is a different kind of problem. Any company you forgot, any table that failed and was not fixed, any scope decision you wanted to revisit, all of that has to be settled while replication is still repeatable.
This is why Microsoft recommends running the whole thing against a sandbox first and only then against production. The sandbox run is not a formality. It is the only place where the irreversible step is reversible.
How many passes it actually takes
“Rerun as needed” is accurate and useless for planning. In the GP to Business Central migrations we have delivered, a typical client needs three to five full test replication passes before the data is clean enough to commit to the final upgrade.
They are not repetitions of the same work. Each pass has a different job.
Pass 1, baseline discovery. This is where the structural blockers surface: SQL and Data Factory pipeline failures, character encoding mismatches, missing master data mappings such as GP account segments to Business Central dimensions, and corrupt inactive vendor and customer records that nobody has looked at in years.
Passes 2 and 3, remediation and iteration. Cleansing orphaned transaction headers, resolving out-of-balance historical sub-ledgers, and tuning posting group mappings. This is the bulk of the effort and it is data work rather than technical work, which is why it needs the finance team rather than the platform team.
Passes 4 and 5, dry-run validation. Run against a fresh production backup, under realistic cutover downtime constraints, until automated balance and inventory reconciliations pass with zero unhandled table errors. The freshness matters: validating against a three-week-old extract tells you about a state that no longer exists.
Plan for the middle passes. They are where the schedule goes if the data is worse than expected, and the first pass is what tells you whether it is.
The third one-way door: the overwrite
This one is stated as an Important callout and deserves more prominence than it gets.
Do not set up cloud migration for a production environment that is already in use for business. Any existing data in Business Central online is overwritten with data from the on-premises source once replication runs. And the warning extends further than most people read: even if your migration targets a *different company* in that environment, you risk the upgrade overwriting data shared across companies in the target.
That matters for a specific and increasingly common case. An organisation already running Business Central online for one entity, migrating a second entity off GP, will reasonably assume the two are isolated because they are separate companies. They are not isolated for this purpose.
The safe pattern is a dedicated target environment for the migration, not a spare company in a live one.
Our position: the assessment before the plan
Microsoft publishes a migration assessment tool that evaluates readiness, suggests migration options and detects potential issues based on your GP system structure. In our view running it should precede any timeline commitment, and it is free, which makes the argument short.
The reason we push it is not the tool’s output. It is that the assessment forces a scope conversation about historical data and company selection while those are still cheap decisions. After the upgrade, they are not decisions at all.
We would not run a GP migration without a sandbox pass that goes all the way through data upgrade and validation. Not replication alone, the full sequence. In our engagements the problems that surface at upgrade are a different class from the ones that surface at replication, and a sandbox run that stops after replication has tested the reversible half of the process.
The counterweight, in fairness: this tooling is genuinely good and most GP migrations are less painful than the ones people remember from the NAV era. The risk profile is not “will the data arrive”. It is concentrated almost entirely in three steps that cannot be undone, which is a much more manageable problem than a general fear of migration.
Why replication cannot tell you the upgrade will work
The sandbox dry run must always run completely through the data upgrade rather than stopping at replication, and the reason is structural rather than cautious.
Replication only copies raw GP tables into a cloud staging schema. It is a data movement exercise, and Data Factory will happily move something that Business Central will later refuse. The data upgrade is the schema-transforming step: it unbundles those GP tables and injects records into native Business Central operational and ledger tables, G/L Entry, Cust. Ledger Entry, Item Ledger Entry. That transformation is where business rules get enforced, and it is the part that cannot be repeated.
Three classes of problem surface only at that step, and replication reports none of them:
General ledger and dimension validation failures. Replication copies GP account strings without complaint. The upgrade then enforces Business Central dimension rules, including mandatory code rules and unmapped segment combinations, and the routine fails mid-transformation.
Sub-ledger imbalances and rounding mismatches. Open AP and AR transactions carrying historical partial applications, or multiple currency exchange rate discrepancies, fail when Business Central attempts to reconstruct the open document balance entries. The rows copied perfectly. They just do not reconcile once rebuilt.
Inventory valuation and unit of measure collisions. GP tolerates loose decimal precision and historical UOM definitions that Business Central’s inventory costing engine rejects during posting, producing aborted table upgrades that replication never flagged.
The pattern is the same in all three: GP was permissive, Business Central is not, and the enforcement happens on the far side of the irreversible step. A sandbox run that stops at replication has tested the half of the process that was never going to be the problem.
Where this sits commercially
Two connections worth making. And if the migration is being questioned on the grounds that the business has outgrown Business Central, the operational limits are the test to run first.
The migration itself is a project cost, and it lands inside the implementation share rather than the licence share. If you are budgeting, what a Business Central implementation actually costs sets out why the subscription is the smallest line, and a GP migration sits squarely in the data migration activity that consistently exceeds its estimate.
And how you buy the subscription, through licensing and CSP, is a separate decision from how you migrate, though the two are often bundled into one conversation by whoever is quoting.
Where to start
Run the free assessment before agreeing a date to any GP to Business Central migration. Then confirm three things in order: that your SQL Server and compatibility level meet the prerequisites, that you have a dedicated target environment rather than a live one, and that at least one user per company holds SUPER before anything is connected.
Then plan the sandbox run as a full sequence through upgrade and validation, and treat the production upgrade as the commit point it is.
Veratas delivers Dynamics migrations onto Business Central, including the scope decisions that have to be made before the irreversible steps.
If you are planning a move off GP and the plan does not identify where the one-way doors are, talk to our team. Those three points are where the risk actually lives.
Frequently asked questions
Which GP versions can migrate to Business Central online? Dynamics GP 2015 and later. The on-premises solution must run SQL Server 2016 or later with database compatibility level 130 or higher.
Can we rerun a GP migration if something goes wrong? Replication can be rerun as often as needed. The data upgrade that follows cannot: once it has run successfully you cannot replicate again from an earlier version without risking corruption from mixing upgraded and non-upgraded records.
What data migrates from GP? System and company setup, master data for accounts, customers, vendors and items, transactional data, classes, Vendor 1099 and historical data. Which company data is included is configurable during setup.
Can we migrate into an environment we already use? No. Microsoft warns against configuring cloud migration for a production environment already in use, because existing online data is overwritten. The risk extends to other companies in that environment, because shared data can be overwritten too.
Why can users no longer edit anything during migration? Non-SUPER users are automatically assigned the Intelligent Cloud permission set, making the tenant effectively read-only so that replication does not overwrite work. Users added after configuration are not assigned it automatically.
Does our GP security model migrate? No. Azure Data Factory moves data using SQL permissions only and does not interpret application permissions, so security setup is a separate task on the Business Central side.
How many test migration runs should we expect? Typically three to five full replication passes. The first uncovers pipeline blockers, encoding mismatches and missing master data mappings. The middle passes are data cleansing, orphaned headers and out-of-balance sub-ledgers. The last are dry runs against a fresh production backup under realistic cutover timings.
Why can a successful replication still fail at upgrade? Because replication only copies raw GP tables into a staging schema, while the upgrade transforms them into native Business Central ledger tables and enforces business rules. Dimension validation, sub-ledger reconstruction and inventory costing all reject data that copied without error.
Should we run a sandbox migration first? Yes, and it should run all the way through data upgrade and validation rather than stopping at replication. The sandbox is the only place where the irreversible step can be repeated.
Senior Business Intelligence Architect with 22 years of experience designing enterprise analytics and data platforms. Focus areas include Power BI, real-time analytics, and large-scale BI architecture across the Microsoft data stack.