Dynamics 365 data migration: how to plan it, which tools to use and how to avoid a bad go-live

A migration strategy is a short written document, agreed before anyone writes a load script. It answers four questions. Which records move, and from which date? Which system is the source of truth for each one while both systems run? Who in the business owns the quality of each data set? And what counts as a successful load, in numbers someone can check?

Start with the first question. Moving every record you have ever created is the slowest and riskiest option. A common pattern is to move all active master data (customers, contacts, vendors, products), open transactions (open quotes, orders, cases, invoices) and opening balances, then keep closed history in a read-only archive or a reporting database. People can still look up an old order, and Dynamics 365 starts clean.

Write down what will not move as well. A list of retired fields, dead picklist values and duplicate records that will be merged saves arguments during testing, when someone notices a field is missing. Decide too which account runs the loads: a dedicated migration user with a temporary role, removed after cutover, as described in our Dynamics 365 security and compliance guide.

Dynamics 365 is two platforms, and the tools differ. Sales, Customer Service, Field Service and Customer Insights store data in Dataverse. Finance, Supply Chain Management and the other finance and operations apps load data through data entities and data packages in the Data management workspace.

Many projects move into both at once, for example a CRM system into Sales and an old ERP into Finance. Treat them as two migrations with one shared customer and product list, and agree which side creates a new customer after go-live. If you are moving to Business Central instead, our Business Central data migration checklist covers that product.

The same three problems cause most delays. Data cleanup starts too late, so the first rehearsal turns up a long list of errors a few weeks before go-live. The load order is wrong, so child records fail because a parent was not there yet. And nobody owns the sign-off, so the cutover weekend ends with a debate about whether the numbers are close enough.

Microsoft's Success by Design implementation guide treats data migration as a workstream with its own plan and owner for the same reason. If a migration is already behind, our project rescue work usually starts with the reconciliation sheet, because it shows exactly which tables are not ready.