Business Central Data Migration Checklist [2026]

A Business Central migration succeeds or fails on two things: loading data in dependency order, and refusing to cut over until a three-way reconciliation between legacy subledger, staging and target reads $0.00. Everything else in this checklist exists to make those two possible.

Most migrations succeed on paper and fail at the first close. Records land, counts match, and then the trial balance is out by a few thousand that nobody can explain. That difference does not go away \u2014 it becomes a permanent feature of the accounts.

1. Before anything moves

1. Freeze the source chart of accounts. A migration against a moving chart is a migration you will run twice.
2. Decide what is in scope: open items and balances, or history as well. Choose open items and balances.
3. Identify every custom field in the source that has a business meaning. Half of them will turn out to be dimensions.
4. Agree the reconciliation gate in writing, with a named owner, before the plan is approved.
5. Get a copy of the source trial balance as at a fixed date. That document is what you will reconcile against.

2. The dependency sequence

This order is not stylistic. Each step depends on the one above it existing and being correct, and loading out of sequence produces records that import cleanly and then post to the wrong place.

Posting groups at step three are where most migrations quietly go wrong. A customer imported before its posting group exists will import successfully and post to a default account, and nobody notices until the first invoice.

3. Extraction and transformation

Use RapidStart configuration packages for master data. They enforce Business Central\u2019s own validation on import, which catches a class of errors that a direct table load silently accepts.

Log every rejected record and resolve all of them before proceeding. A migration that reports "98% loaded" has an unreconciled two percent, and that two percent is disproportionately the difficult records \u2014 the ones with missing dimensions, odd currencies or historical oddities.

4. Validation in the sandbox

Load into a sandbox and run the real validation, which is not a record count.

1. Trial balance in the sandbox against the frozen source trial balance, account by account.
2. Aged receivables and payables, bucket by bucket, not just in total.
3. Inventory valuation by location and by item, against the source.
4. A sample of ten transactions traced end to end, source document to ledger entry.
5. A full period close, run in the sandbox. This is the step most teams skip and the one that finds real problems.

If the sandbox close does not produce the same numbers as the source, the cutover will not either. Fix it here, where the only cost is time.

5. The cutover weekend

1. Freeze the source. No postings, enforced by permissions and not by email.
2. Take the final source trial balance. This is the number the gate is measured against.
3. Run the delta load for everything that moved since the last full sync.
4. Run the three-way reconciliation: legacy subledger, staging, target.
5. Gate: variance reads $0.00, or the cutover stops and the rollback runs.
6. Open to users only after the gate passes.

Step five is the whole checklist. Everything before it is preparation for being able to answer one question honestly at two in the morning, when the pressure to accept a small difference is highest and the cost of accepting it is permanent.

6. After go-live

Hypercare runs until the first month-end closes cleanly, not until go-live weekend ends. The first close is the first time anyone genuinely knows whether the migration worked, and it is the last moment where fixing something is cheap.