Data migration strategy for Dynamics 365

By Emil Björk · Microsoft business apps consultant, Gothenburg

How to plan and run a data migration into Dynamics 365 — scope, tools, cycles, reconciliation, and the cultural side that breaks projects.

Reviewed May 20262 min read · 447 wordsPublished
On this page (7)

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:

  1. 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.
  2. 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.
  3. 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:

The cycles

Plan three to four migration cycles minimum:

  1. Dry run 1 — structural test. Push everything, accept errors, find the messy fields. Surface unexpected mapping problems.
  2. Dry run 2 — content rehearsal with cleansed data. Users validate samples.
  3. Mock cutover — full end-to-end including the cutover process, timing, and reconciliation. Identifies the slow steps in the real plan.
  4. Real cutovergo-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.

Where to go next

Product-specific mechanics: Business Central data migration, the data management framework for Finance and Supply Chain, and Dataverse data import templates. Test cycles need test data management, and the final load is the centrepiece of cutover planning.

Related guides

Browse every guide in Implementation or just Project execution.

Was this helpful?

Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.

Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.