Each old system leaves a different kind of mess
A company coming off Dynamics NAV usually has years of clean, structured data plus a layer of custom code written in C/AL. The data can travel; much of the code should not, because current Business Central often covers what those modifications were written to do. Dynamics GP and SL bring their own account segment structures, which need to be translated into a chart of accounts and dimensions rather than copied field for field.
QuickBooks, Sage and Xero customers face a different problem. Their data is simpler, but it was often entered with less discipline: duplicate vendors, items that are really services, customers stored under three spellings. Spreadsheet businesses have the least to move and the most to design, since Business Central will ask questions about posting groups and costing methods that nobody has had to answer before.
Separate pages for each source system are on the way. The principles below apply to all of them.
What normally comes across and what is left behind
Opening balances versus bringing the history
Balances only
The fastest and cleanest option. The trial balance at cutover, open receivables and payables, and stock on hand are loaded; everything older stays in the old system or an export. Auditors are generally comfortable with this when the old data remains readable.
Summarized history
Net change per account per month for the current and previous fiscal year is posted, so year-over-year reports work inside Business Central from day one without the weight of every transaction.
Full transaction history
Possible from some sources, especially GP and NAV through Microsoft's cloud migration tool, which can bring historical detail across. It increases testing effort, and the value falls off quickly for anything older than a couple of years.
Read-only archive
Whatever does not move still needs a home. That can be the old system on a reduced license, a reporting database, or structured exports your team and auditors can search. We decide this before the cutover date, not after.
From the old books to the first live posting
- 1
Inventory the data
Count what exists in the source: record volumes, open items, custom fields and integrations. This is where surprises such as a second, forgotten company or a payroll feed usually appear.
- 2
Clean before moving
Duplicates are merged, dead records marked inactive and codes standardized in the old system or in the staging workbook. Cleaning after go-live costs more and confuses users.
- 3
Map and load into a sandbox
Fields are mapped to Business Central tables and loaded with configuration packages, the cloud migration tool or both. A sandbox takes the first loads so mistakes cost nothing.
- 4
Reconcile trial loads
Balances, aged receivables, aged payables and inventory valuation are compared line by line against the source. Nobody signs off until the numbers tie.
- 5
Parallel run where it matters
For payroll-linked or high-volume processes, a period is processed in both systems and the results compared. For simpler businesses a careful dress rehearsal of the cutover is often enough.
- 6
Cutover
The old system is frozen, final balances and open documents are loaded, the first transactions are posted in Business Central, and the archive plan takes effect.

Traps that slow a migration down
- βTreating the migration as a copy job instead of a chance to fix the chart of accounts.
- βLeaving vendor bank details and tax IDs unverified until the first payment run.
- βLoading inventory without agreeing the costing method first, which is hard to change once items have posted entries.
- βForgetting integrations such as ecommerce, EDI, payroll or banking that quietly read from the old system.
- βChoosing a cutover date in the middle of a quarter-end close or a peak sales week.
Questions from companies planning the move
Can we migrate to Business Central in the middle of our fiscal year?
Yes. Many companies go live at a month end rather than a year end. The trial balance at that month end becomes the opening position, and summarized net change for earlier months in the year can be posted so year-to-date reports still work. Year end is tidier, but waiting for it is not required.
Does Microsoft provide tools for moving our data?
Microsoft includes a cloud migration tool in Business Central online for Dynamics GP and for on-premises Business Central databases, and it has been adding routes for older products over recent releases. For NAV, the path depends on the version you run. For QuickBooks, Sage, Xero and spreadsheets, configuration packages and Excel templates are the usual method.
What happens to our NAV customizations?
Each one is reviewed. A good share typically turns out to be covered by current standard features, so it is simply dropped. The rest are rebuilt as AL extensions, which is the only way to customize Business Central online, and those extensions then survive Microsoft updates.
How much history should we bring across?
Usually less than people expect. Open items and balances are essential; one or two years of summarized history covers most comparative reporting. Detailed older transactions are better kept in a searchable archive, which keeps the new system fast and the testing effort reasonable.
Who does the data cleanup?
It is shared. We provide the templates, the rules and the checks that find duplicates and gaps, while your team decides which customer record is the right one and which items are still sold. Nobody outside your business can make those calls reliably.
Talk to us about your project.
Tell us what you run today and what has to change. A senior consultant replies with a written next step.
