How to migrate to Business Central without losing your data

A Business Central migration rarely fails because of the software. It fails because nobody decided which data deserved to move, who would sign off the opening balances, or what would happen if the first month-end close did not reconcile. This page explains how to move to Business Central from the systems UK companies typically leave behind, and how to handle moves between Business Central versions.

If you are still at the stage of choosing a platform, start with the Business Central overview for the UK and the wider ERP migration guide. The rest of this page assumes you have decided to go ahead and want to know how the move works.

Where are you migrating from?

The source system decides the method. Most UK projects fall into one of four situations.

The first three are re-implementations in all but name. You are not copying a database; you are deciding how the business will run in the new system and loading the data it needs. The fourth group can use the vendor's own tools, covered below.

Microsoft's tooling for moving to Business Central online

Microsoft provides a cloud migration tool that moves data into Business Central online. According to Microsoft's documentation, the supported sources are:

• Business Central on-premises, directly from version 25; versions 15 to 24 must first be upgraded to at least version 25;
• Dynamics GP 2015 and later;
• Dynamics SL 2015 and later;
• any other SQL source, through custom migrations.

Some conditions matter before you start. The on-premises solution must run on SQL Server 2016 or later, with a database compatibility level of at least 130. A company on Dynamics NAV must first move to Business Central on-premises before it can switch to the online service.

For a company on version 14 on-premises, Microsoft describes two options. The first is a full migration: upgrade on-premises to version 25 or later, then migrate. The second is the Business Central 14 re-implementation tool, which carries only the essential data (master data, opening balances and setup) directly to the cloud. The second option suits a company that wants a cleaner start and is happy to leave transaction history behind.

If the source is not SQL-based, Microsoft's guidance is to use configuration packages and templates to load the data into an on-premises Business Central, then use the cloud migration tool to go online. In practice, many integrators load into a sandbox environment first, check it, and only then repeat the load for production.

Where you plan to stay on-premises or in a partner-hosted setup, read the hosting and cloud options before you fix the target.

Which data should you migrate?

The temptation is to bring everything. Resist it. A migration is the one moment when a company can leave years of clutter behind.

Master data

Customers, suppliers, items, bills of materials, bank accounts, dimensions and the chart of accounts form the base. Clean them before loading: duplicate customers, suppliers with no activity, stock codes that mean the same thing under three names and inactive accounts all slow the project down and confuse users on day one. Ask the people who use the data to approve the cleaned lists, not just the person who exports them.

Opening balances

Opening balances are where finance teams spend the most time. The usual set is the trial balance at the cut-over date, plus the open items behind it: the sales ledger by invoice, the purchase ledger by invoice, bank balances, fixed asset values and stock valuation. Each of these must reconcile to the control account in the opening trial balance. The Microsoft examination for Business Central functional consultants explicitly covers opening journal entries, configuration packages and data migration, which shows how central they are to the work.

For a UK business, check VAT carefully. Open invoices must carry the right VAT treatment so that the first VAT return from the new system is correct. The guide to Making Tax Digital and your ERP explains what the system has to support. The same applies to payroll and RTI if payroll is part of the scope: starters, leavers and year-to-date figures must reconcile before the first submission from the new setup.

Open transactions

Open sales orders, purchase orders, production orders, stock in transit and unpaid invoices should move so that nothing has to be re-keyed. Decide a rule for orders in flight at the cut-over date: either they are completed in the old system, or they are recreated in the new one. Mixing the two causes duplicate shipments and missing invoices.

Historical data

History is a business decision, not a technical one. The usual options are:

1. Load summarised history, such as monthly balances by account, so that comparisons are possible.
2. Load detailed transactions for the current and prior financial year only.
3. Keep the old system or an archive in read-only mode for audit and enquiries.

Keep in mind what your accountant, auditors and HMRC may need to see, and for how long. The right answer depends on your sector and your record-keeping obligations; ask your accountant before deleting anything.

Building the migration plan

A workable plan has the same ingredients whatever the source.

Map before you load

Create a mapping document that shows, field by field, where each piece of source data lands in Business Central. Include the chart of accounts, dimensions, payment terms, VAT groups, posting groups and units of measure. The mapping workshop often reveals process questions that would otherwise only appear after go-live. If you have not yet written your requirements, the ERP requirements template is a good starting point.

Rehearse several times

A single load into production is a gamble. Serious projects run repeated trial migrations into a sandbox: a first load to find structural problems, a second to check reconciliation, and a final dress rehearsal that times the whole cut-over weekend. Every rehearsal produces a list of errors, and the list should get shorter each time.

Test with business users

Technical checks (record counts, totals, referential integrity) are necessary but not sufficient. Ask the credit controller to find a known customer and check the aged balance. Ask the buyer to raise an order against a migrated supplier. Ask the warehouse to pick an item with real stock. Acceptance should be signed by the people who will use the system, against criteria agreed in advance. The implementation page shows where these tests sit in the wider project.

Train before the switch

Users who see the new screens for the first time on the morning of go-live will keep working in the old system in parallel, and the migrated data will drift. Schedule training on the migrated test data so that the examples feel real.

Choosing the cut-over strategy

There are two broad approaches.

Most UK companies choose a cut-over at a period end, usually a month-end or the start of a financial year, so that opening balances are clean and the VAT quarter does not straddle two systems. Avoid year-end audit work, peak trading periods and payroll deadlines where you can.

Parallel running, where both systems are fully updated, doubles the work and tends to produce two versions of the truth. A better pattern is a short, defined period in which the old system is read-only, and the new system is the only one that accepts transactions.

The rollback plan

Every migration plan needs an answer to a plain question: if the first morning shows serious problems, how do we go back, and who decides?

A usable rollback plan includes:

• a named decision-maker and a fixed decision point, such as a checkpoint after the first full reconciliation;
• the old system preserved, backed up and ready to resume, with no transactions lost between the freeze and the decision;
• a record of everything entered in the new system after go-live, so that it can be re-entered if you revert;
• a tested restore procedure for the new environment.

On the Business Central side, Microsoft allows an environment to be restored up to ten times in a calendar month, to any point in the previous twenty-eight days, within the same Azure region and location. A restore is only possible with a paid subscription. That is a useful safety net during a go-live, but it restores the environment, not your business: bank feeds, integrations and anything that left the system in the meantime will not be rewound. Your integrator should rehearse a restore in a sandbox so that nobody learns how it works in the middle of an incident.

Migrating between Business Central versions

Business Central online is a service rather than a product you upgrade once every few years. Microsoft states that it follows the Modern Lifecycle Policy, with continuous service updates and a major update every six months. Two major updates are released each year, in April and October, with minor updates each month in between. They include critical fixes and regulatory changes.

For the customer, version migration is therefore a recurring routine:

• The update period for a major version starts at general availability, usually the first working day of April or October, and lasts five months. The version is offered to existing environments around a week later, followed by a month of grace.
• Preview sandboxes open about a month before release, in March and September, and are deleted thirty days after official availability. Use them to test your extensions and reports against the coming version.
• Each environment has a default update window between 8 pm and 6 am local time. An administrator can change it, with a minimum length of six hours. An update that does not finish within the window is cancelled and rescheduled seven days later.

The practical consequences are clear. Keep a sandbox that mirrors production. Run your key processes in the preview before each major version. Avoid setting an update window that collides with a month-end close, a VAT deadline or a payroll run. And if you have customisations or third-party integrations, check with their suppliers that they will be compatible before the update reaches production. The versions and editions page covers the differences in more detail, and support and maintenance explains who should own this routine after go-live.

Common mistakes to avoid

• Migrating dirty data. Duplicates and obsolete records do not become tidier in a new system.
• Underestimating opening balances. A trial balance that does not reconcile at the cut-over date is the most common cause of a delayed go-live.
• Loading all of the history. More history means longer loads, longer tests and more questions, for data that is rarely consulted.
• Skipping the rehearsal. The first time you time the cut-over should never be the real one.
• Ignoring UK compliance. VAT codes, Making Tax Digital submissions and payroll reporting must work from the first period, not the second.
• No owner on the business side. Someone in finance and someone in operations must own data quality. The integrator can load the data but cannot decide what is right.
• Forgetting the rollback. Without a plan, any problem on the first day becomes a crisis.
• Treating updates as an afterthought. A company that migrates carefully and then ignores the update cycle will find the next major version a surprise.

Other typical pitfalls are listed in the guide to ERP project mistakes. If a migration is already under way and going badly, an independent audit or project rescue is often cheaper than pressing on.

Finding the right partner for the move

A good migration partner will ask about your data before they talk about the software. They will want to see the chart of accounts, a sample of master data, the list of integrations and your reporting calendar. They should be able to explain how they rehearse, how they reconcile and how they handle rollback. Our guide to choosing a Business Central partner lists the questions to ask, and the pricing page explains what drives licence and project costs. ERP Integrator is a free matching service: tell us about your current system, your data and your timetable, and we introduce you to a certified integrator suited to the project. The integrator carries out the migration.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.