Data migration to Business Central: what should you consider?

A data migration to Business Central succeeds in four steps: first decide what gets migrated at all, because history rarely belongs. Then cleanse the master data before it reaches the new system. Then migrate in test runs, reconciled against the legacy balance sheet. Finally the live run with a fixed data cut-off date. Whoever takes over legacy data uncleansed migrates their problems along with it.

What gets migrated, and what deliberately does not?

The standard scope is smaller than many expect: master data such as customers, vendors, items and general ledger accounts, plus open entries, open documents and stock as at the cut-off date, plus opening balances. That is enough for a clean start.

Transaction history in most cases does not belong in the new system. It clogs the data foundation with legacy structures and costs a multiple of its value during migration. For analysis, the history stays readable in the legacy system or moves into an archive or a reporting model. There are exceptions, such as legal requirements or serial-number traceability, but they should be justified, not the reflex.

The split follows one simple question: does day-to-day work need this record, or does only traceability need it? The first goes live, the second into an archive that is read when needed, without burdening the new system.

Why does cleansing matter more than the tool?

Whether via configuration packages, RapidStart or a migration tool: the technical transport is a solved problem. What delays projects are duplicates in the customer base, items without an owner, vendors spelt three different ways, and accounts that have served as catch-alls for years.

Hence the order: cleanse first, then migrate. A new system does not automatically improve data quality, it makes it visible. The migration is the best opportunity in years to bring the data foundation up to the standard the business needs, and it will not come around again soon.

Tools reliably solve the transport problem but not the problem of meaning. Whether a field was used for its intended purpose or for something else over the years is invisible to any tool, and it is precisely that clarification which considerably extends migration projects in the end.

How does a migration actually run?

• Define the scope: which data objects, which cut-off date, which exceptions
• Define the mapping: legacy fields to Business Central structures, including dimensions
• Cleanse in the legacy system or in an interim step, with named owners per data object
• At least two test migrations with reconciliation: totals, balances, open entries against the legacy system
• Live run on the cut-off date, with the legacy system frozen and the reconciliation documented

Test migrations are where people cut corners, and where it backfires most bitterly. Only the second test run shows whether mapping and cleansing really hold, because the first almost always brings surprises. Going live straight after the first run moves the test into live operation.

The test run is the step most often dropped, and the only one that secures the others. Without it, it only emerges on the migration weekend whether the balances and references add up, and by then there is no time for an orderly correction.

Who carries responsibility for the data?

Not the partner and not IT, but the business department that owns the data: sales for customers, purchasing for vendors, product management for items, finance for accounts and balances. The partner builds tools and mapping, but only the business can decide whether a customer is a duplicate.

In practice this means: one named person per data object who signs off. These sign-offs are no formality; they are the quality assurance of the future data foundation on which every automation and every AI agent will later work.

The answer is always: the business, not IT. IT provides the tools and the transport, but whether a customer record is correct can only be judged by whoever works with those customers. Without named owners per data object, data quality remains a collective responsibility nobody really holds.