Across 240+ Dynamics 365 implementations, the single strongest predictor of an on-time go-live is not the size of the configuration backlog. It is how early the programme made five specific data decisions. Teams that settled them before the first build sprint went live on the committed date in the overwhelming majority of cases. Teams that deferred them slipped, usually by a full quarter.
1. Decide what does not migrate
The default instinct is to bring everything. It is also the most expensive choice available. Open transactions, current-year balances, and active master data belong in the new platform. Ten years of closed history usually belongs in a read-only archive with a reporting view over it.
- Migrate: open AR/AP, open orders, inventory positions, active customers, vendors, items, employees
- Archive: closed periods, superseded price lists, inactive records with no compliance requirement
- Rebuild: derived analytics that should be recomputed in Fabric or Power BI rather than carried over
2. Name a business owner for every data object
IT can own the pipeline. It cannot own the definition of a customer, a cost centre, or a product hierarchy. Every object needs one named business owner who signs off the mapping, the cleansing rules, and the reconciliation result. When ownership is diffuse, sign-off collapses into the final week and the go/no-go gate becomes a negotiation instead of a decision.
3. Cleanse in the source, not in the pipeline
Transformation logic that quietly repairs bad source data hides the problem and guarantees it returns. Fix duplicates, missing tax identifiers, and broken hierarchies where they are created. The migration pipeline should be deterministic and boring: extract, map, validate, load.
4. Rehearse at full volume, three times
A mock load at 10% volume proves the mapping compiles. It proves nothing about the cutover window. Run three full-volume rehearsals: the first to establish duration, the second to compress it, the third to prove repeatability with the final runbook and the actual people who will execute it at 2am.
- Mock 1 — mapping correctness and load duration baseline
- Mock 2 — performance tuning, parallelisation, reconciliation automation
- Mock 3 — dress rehearsal against the signed runbook, timed end to end
5. Define reconciliation before you define the cutover date
The go/no-go gate should be a set of numeric tolerances agreed with Finance months earlier: trial balance variance, inventory valuation variance, open-order count, and customer/vendor counts. If reconciliation is designed on cutover weekend, the decision becomes a judgement call under pressure — which is how programmes go live with data nobody trusts.
“Every wave went live on the committed date because the data decisions were closed before the build started.”
What this looks like in practice
On a recent four-ERP consolidation across six plants, this discipline cut month-end close from nine days to four and reduced inventory carrying cost by 17%. None of that came from clever configuration. It came from a migration scope that was frozen early and reconciled to tolerances Finance had already accepted.
