How a safe migration to Business Central actually works

2026-07-16 · 7 min read

Three-stage migration diagram: map and clean the data, run the new system in parallel with the old, then a planned cutover with support through the first close.What a safe migration actually looks like1. Map & cleanknow what you have, fix it before it moves2. Parallel runboth systems live, nothing bet on one day3. Cutoverplanned switch, support through first closeYour history comes with youopening balances, ledgers and audit trail preserved - not left behindThe fear is disruption. Staging removes it.

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.

Three-stage migration diagram: map and clean the data, run the new system in parallel with the old, then a planned cutover with support through the first close.What a safe migration actually looks like1. Map & cleanknow what you have, fix it before it moves2. Parallel runboth systems live, nothing bet on one day3. Cutoverplanned switch, support through first closeYour history comes with youopening balances, ledgers and audit trail preserved - not left behindThe fear is disruption. Staging removes it.

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.
Take the free readiness check

Take the free readiness check

← All insights