Data Migration Best Practices for Business Central Implementations

Data migration is the part of a Business Central implementation that most senior leaders underestimate and most implementation partners have seen go wrong. It is not a technical task that sits at the end of the project. It is a business decision that needs to start near the beginning, run as a workstream in its own right, and involve the people who understand the data, not just the people who can move it.

The businesses that navigate this well, will go live on schedule with clean data and confident users. The ones that do not tend to discover their data problems on go-live day, when fixing them is at its most disruptive and expensive.

Here is what good looks like across the critical stages.

Start with scope, not migration

Before any data moves, the first decision is what moves at all. Not everything in your legacy system needs to come across to Business Central. In many cases, a significant proportion of historical data is better archived than migrated.

The categories to think through are: open transactions that need to be live on day one, historical data required for reporting and compliance, and static data such as customer, supplier, and product records. Each category has different cleansing requirements and different risk if it is wrong.

Deciding scope upfront removes a significant amount of migration work and reduces the risk of carrying legacy data quality problems into the new system.

Data cleansing is not optional

Legacy data quality is almost always worse than expected. Duplicate supplier records, inconsistent product codes, incomplete customer information, and coding structures that reflect how the business operated five years ago rather than how it operates today.

The time to clean this data is before migration, not after. Migrating poor quality data into Business Central does not fix the problems. It embeds them in a new system and adds the complexity of having gone live with inaccurate information.

Data cleansing requires business ownership, not just IT effort. A Finance Director or Financial Controller who understands what the data should look like needs to be involved in reviewing and signing off cleansed data before it is loaded.

Data mapping: where the technical and business understanding meet

Data mapping is the process of defining how fields in your legacy system translate into Business Central. Some of this is straightforward. Some of it requires decisions about how the new system is structured and what conventions will be used going forward.

Common mapping decisions include how your chart of accounts maps to Business Central's structure, how products and pricing are represented, and how customer and supplier master data is normalised across what may have been inconsistent records.

These decisions should be documented. Poor mapping documentation is one of the most reliable sources of post-go-live issues, because nobody can remember why a particular decision was made when it surfaces as a problem three months later.

Testing and validation before go-live

Data migration is not complete when the data is loaded. It is complete when it has been validated against the source and confirmed to be accurate by someone who understands the business.

A structured validation process involves running parallel reports in the legacy system and Business Central, comparing key figures such as debtor balances, creditor balances, and stock valuations, and having the finance team sign off that the numbers are right before the switch is made.

This is not the implementation partner's sole responsibility. Dynamics 365 Business Central services includes support through this process, but the sign-off needs to come from the business. Ownership of data accuracy sits with the organisation, not the delivery partner.

Go-live and the data confidence question

The most common question on go-live day is: can we trust these numbers? The answer to that question depends entirely on how thoroughly the preceding stages were executed.

If data was cleansed properly, mapping decisions were documented, and validation was completed by the right people, the answer should be yes. If any of those stages were rushed, the answer is probably not yet, and the business faces a stabilisation period that is longer and more disruptive than necessary.

For CEOs and Managing Directors, the oversight question during implementation is not about the technical details. It is about whether the data validation process was structured properly and whether the right business people were involved in it. 

Frequently asked questions

What are the best practices for data cleansing before Business Central migration?

Start with a data audit to understand the quality and volume of what you have. Categorise data by what is needed at go-live, what is needed for compliance, and what can be archived. Assign business ownership for cleansing decisions, since IT can move data but only the business can confirm what correct looks like.

How can businesses ensure accurate data mapping during migration?

Document every mapping decision, including the rationale. Involve someone who understands the business data model as well as someone who understands Business Central's structure. Review the mapping against real-world scenarios before loading, and keep the documentation current throughout the project.

What is the most common challenge during Business Central data migration?

Data quality. Legacy systems accumulate duplicates, inconsistencies, and outdated records over years. These are rarely as clean as the business believes at the start of a project. Building adequate time for cleansing into the project plan, and involving the right business stakeholders in that process, is the most reliable way to manage it.

What are the four types of data migration relevant to Business Central?

The main categories are master data (customers, suppliers, products), transactional data (open invoices, purchase orders, stock levels), historical data (prior period transactions for reporting), and configuration data (chart of accounts, payment terms, tax codes). Each has different risk profiles and different cleansing requirements.

How can CEOs and Managing Directors maintain accountability during data migration?

By requiring clear sign-off gates. Before go-live, the finance lead should formally confirm that key balances have been validated against the legacy system. That sign-off should be documented. It creates accountability and ensures the business, rather than the implementation partner, owns the accuracy of the data going into the new system.