How a safe Business Central migration works
Moving accounting systems sounds risky. Done in stages it isn't. The three-stage shape of a clean migration, what happens to your history, and the mistakes that turn a straightforward move into a horror story.
The biggest blocker to moving off outgrown software is almost never cost. It is 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 safe Business Central migration is built specifically to remove them.
A safe migration has three stages: map and clean the data, run the new system alongside the old, then cut over on a planned date with support through the first close.
Stage 1: Map and clean
Before anything moves, 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 chance to leave that behind, and dragging it across is the most common own goal.
Business Central helps here. Microsoft's guide to importing data describes templates for accounts, customers, vendors and items, a default configuration package for master data, and an extension for migrating from QuickBooks.
Key PointData quality decides how smooth everything after it feels. Expect this stage to take longer than you think and to be worth more than you expect.
Stage 2: Parallel run
The new system runs alongside the old for a period, with real transactions going 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 real confidence before you commit.
Pro TipAgree in advance which reports you will compare during the parallel run, such as the trial balance and the customer and supplier balances, and who signs them off.
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?
This is the most common question, and the answer is reassuring. There are three options, usually combined:
- Opening balances brought in as at the cutover date, which is always done
- Transactional history for a recent period, migrated so you have comparatives
- The old system kept read-only for anything older
Whatever you choose, the records still have to be kept. GOV.UK says a limited company must keep records for 6 years from the end of the last company financial year they relate to, so plan how the old data stays available for that long.
The mistakes that cause horror stories
- Skipping the parallel run to save time, which is where the disasters come from
- Migrating dirty data and inheriting every existing problem
- Cutting over mid-period, which makes reconciliation far harder than it needs to be
- No named owner on your side, so decisions stall
- Treating go-live as the end rather than the first close
Watch OutIf you are VAT-registered, plan the cutover around your VAT quarter. All VAT-registered businesses should now be signed up for Making Tax Digital for VAT, so confirm the new system can file before you switch.
How long it takes
The timeline depends far more on data quality, the number of integrations and how much process changes than on the software itself. Ask for a plan that shows each stage, and budget the time your own team will spend on it.
For the cost side, see our Business Central pricing guide. If you are coming from Xero, the Xero to Business Central migration guide covers the differences in detail, and when to move from Xero to ERP sets out the warning signs. To see the system first, Microsoft offers a free 30-day trial of Business Central.
Frequently asked
Can we run both systems permanently?
You can, briefly, but it doubles the work and brings back the reconciliation problem. Parallel running is a phase, not a destination.
What if we find a problem after cutover?
That is what first-close support is for. Most issues after cutover are configuration tweaks rather than 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, so trading continues.
Who needs to be involved from our side?
One named decision-maker, plus whoever knows how the current processes really work. If you are still deciding whether to move at all, read the hidden cost of staying on the wrong system.
