How a Unit4-to-D365 programme runs: the seven stages, the Unit4-specific discovery inventory, eight-wave data migration dependency order, three mock cutovers, the T-offset cutover timeline, four-corner reconciliation, go/no-go criteria, and the Unit4-specific traps that derail programmes in testing.
A Unit4-to-D365 migration is not simply an ERP replacement. It is a classification exercise (deciding what every Unit4 attribute actually is in D365 terms), a data model design exercise (building D365 structures from scratch because there is no direct schema mapping), and only then a data migration exercise.
Note that stages overlap — Build begins before Decide completes, and Prove begins before Build completes. The overlaps are intentional: they prevent the programme from becoming a waterfall. The gate conditions, however, are strict. Build must not produce extensions for attributes that are not yet partitioned.
Standard ERP discovery — fit-gap workshops, process walkthroughs, data volume analysis — is necessary but not sufficient for a Unit4 migration. Unit4's attribute-based model requires a specific set of discovery deliverables:
Data migration runs in eight waves with strict dependency ordering. A wave cannot begin loading until all its dependency waves have been reconciled.
Mock Cutover 1 (week ~18): Technical feasibility. Execute all migration scripts against a full-volume data refresh of the D365 environment. Measure execution time per wave. Identify script errors, data quality issues and performance bottlenecks. Do not expect to meet the cutover window time target. Produce a defect and action log.
The production cutover runs on a T-offset timeline where T=0 is the go-live moment (users access D365 for the first time). Typical timing:
Four-corner reconciliation validates that D365 and Unit4 agree at the highest level before go-live:
The executive case for a Unit4-to-D365 transition is not only that Unit4 customers want a newer finance system. It is that D365 sits inside a wider Microsoft Cloud estate — M365, Dataverse, Azure, Fabric and Copilot — in a way that changes the operating model after go-live.
The playbook uses W01 to W08 as shorthand for the migration waves. Do not treat those labels as project-management decoration; each label carries a dependency and a reconciliation gate.
A Unit4-to-D365 programme succeeds when the classification exercise (Attribute-to-Destination matrix) is completed thoroughly in Discover phase, structural design decisions are locked in Decide phase before Build begins, three mock cutovers are run to prove the data migration and cutover window, and the four-corner reconciliation is…