Data migration strategy for Dynamics 365
How to plan and run a data migration into Dynamics 365 — scope, tools, cycles, reconciliation, and the cultural side that breaks projects.
Data migration is the silent killer of Dynamics 365 implementations. The technology is fine; the discipline is what fails. Most projects that slip do so because the migration plan is treated as an IT task instead of a business one.
Scope decisions made early. Pick a position on three big questions up front:
- How much history? Trial balance only? Opening balances + 12 months of detail? Three years? Everything? More history adds time, cost, and risk; less history means consulting the legacy system for old enquiries.
- What's the cut? Master data only, or transactional too? Open transactions (orders, invoices, balances) almost always migrate; closed transactions are often deferred to a legacy read-only archive.
- What's the cleanse strategy? Migrate clean or migrate dirty? The honest answer is cleanse before migration — using the project as a cleanup forcing function — but it must be customer-led.
The tools. Each Dynamics 365 product has its preferred path:
- Business Central — Configuration Packages, Data Migration wizard, REST API for high volume.
- Finance / SCM — Data Management Framework (DMF) with data entities, recurring integration patterns for staged loads.
- CRM-side — Dataverse Web API, Power Query Dataflows, Azure Data Factory for bulk, Power Automate for transformations.
The cycles. Plan three to four migration cycles minimum:
- Dry run 1 — structural test. Push everything, accept errors, find the messy fields. Surface unexpected mapping problems.
- Dry run 2 — content rehearsal with cleansed data. Users validate samples.
- Mock cutover — full end-to-end including the cutover process, timing, and reconciliation. Identifies the slow steps in the real plan.
- Real cutover — go-live. No surprises if cycles 1-3 were honest.
Reconciliation. Every migration ends with reconciliation:
- Trial balance ties to opening journals posted in D365.
- AR ageing ties to customer ledger.
- AP ageing ties to vendor ledger.
- Inventory on hand ties to item ledger valuation.
- Open orders / WIP tie to their respective sub-ledgers.
Migrate to the penny or migrate to a known reason for the variance.
The cultural side. Migration projects fail because:
- The customer thinks the partner owns data quality. They don't; the customer does.
- The cleanup work isn't resourced. It takes weeks per business area.
- Source data is more fragmented and inconsistent than anyone admitted.
- "We'll just clean it up after go-live" rarely happens.
Address these in week one.
Sign-off discipline. Each cycle's reconciliation should be signed off by the controller (for finance), the warehouse lead (for inventory), the sales lead (for orders). Without sign-off, go-live ships uncertainty.
Related guides
- Test data management for Dynamics 365How to build and maintain test data for Dynamics 365 environments — anonymisation, synthetic data, data subsetting, and the workflows for keeping non-prod environments useful.
- Budget management for Dynamics 365 implementationsHow to budget and manage costs for a Dynamics 365 project — cost categories, tracking discipline, change control, and the patterns that prevent budget overruns.
- Business process mapping for Dynamics 365How to map business processes for a Dynamics 365 implementation — process hierarchies, BPMN notation, scenarios, and the patterns that produce useful process documentation.
- Change management for Dynamics 365How to run change management on a Dynamics 365 implementation — stakeholders, comms, training timing, and the cultural patterns that decide adoption.
- Change readiness assessment for Dynamics 365 implementationsHow to assess organisational readiness for a Dynamics 365 implementation — readiness dimensions, surveys and interviews, gap analysis, and the interventions that close gaps before go-live.