How a safe migration to Business Central actually works
2026-07-16 · 7 min read
The biggest blocker to moving off outgrown software is almost never cost. It's fear — of losing history, of a switchover weekend that goes wrong, of the business stopping. Every one of those is a design problem, and a good migration is built specifically to remove them.
Stage 1 — Map and clean
Before anything moves, you map what you have: chart of accounts, customers, suppliers, items, open transactions, and the processes that touch them.
This is also the moment to clean. Most systems carry years of duplicates, dead accounts and codes nobody understands. Migration is the one natural opportunity to leave that behind — dragging it across is the most common own goal.
Expect this stage to take longer than you think and be worth more than you expect. Data quality determines how smooth everything after it feels.
Stage 2 — Parallel run
The new system runs alongside the old for a period — typically a month, sometimes a quarter. Real transactions go through both.
This is what removes the risk. Nothing is bet on a single switchover day. You compare outputs, find the differences while the old system is still there, and build genuine confidence before committing. If something's wrong, you find it with a safety net underneath you.
Stage 3 — Cutover and first close
A planned cutover on an agreed date, with opening balances brought across and reconciled. Then — and this matters more than people expect — hands-on support through your first month-end in the new system.
The first close is where questions surface. Having someone alongside for it is the difference between a wobble and a crisis.
What happens to your history?
The most common question, and the answer is reassuring. You have three options, usually combined:
Opening balances brought in as at the cutover date — always done
Transactional history for a period, commonly one to two years, migrated for comparatives
The old system kept read-only for a year or so, for anything older
You don't lose your history. You choose how much of it needs to be live versus available.
The mistakes that cause horror stories
Skipping the parallel run to save time — this is where the disasters come from
Migrating dirty data and inheriting every existing problem
Cutting over mid-period, making reconciliation far harder than it needs to be
No named owner on the client side, so decisions stall
Treating go-live as the end rather than the first close
How long it takes
For a business moving from Xero or QuickBooks to Business Central, a straightforward migration is usually measured in weeks. Complexity comes from data quality, number of integrations and process change — rarely from the software itself.
Frequently asked
Can we run both systems permanently?
You can, briefly, but it doubles the work and reintroduces the reconciliation problem. Parallel running is a phase, not a destination.
What if we find a problem after cutover?
That's what the first-close support is for. Most post-cutover issues are configuration tweaks, not structural faults.
Do we need to stop trading during cutover?
No. A planned cutover happens around a period end with the parallel run behind it — trading continues.
Who needs to be involved from our side?
One named decision-maker, plus whoever knows how the current processes really work. That second person is more important than the first.