The technical spine behind a Unit4-to-D365 programme: the extractor-canonical-transformer-loader-reconciler architecture, the transformation matrix's governance rules, the migration engine's operational hardening register, the cutover-state matrix, four-corner reconciliation with the specific Unit4 and D365 report on each side, and a tiered hypercare model with defect severity and exit criteria.
Chapter 1, Programme shape, waves and sequencing, covers when things happen: the seven programme stages, the eight-wave dependency order, and the T-offset cutover timeline.
A migration engine built as a chain of five stages outperforms one built as a set of point-to-point interfaces, for a simple reason: with n sources and m target entities, point-to-point mapping requires up to n × m individual translations, each maintained separately;
Unit4's Attribute and Relation fluidity — the same fluidity covered from the language and tooling angle in the Development & Architecture modules — makes its canonical lookup registry the largest of any source this programme handles.
D365's Data Management Framework (DMF) is the supported loading channel — never direct SQL, which the Language and runtime chapter already established is unsupported against a production AOS database.
The hardening register is a monitored operating control, not a statement of intent. Each dimension should have a dashboard tile, log query, alert, release check or evidence artefact proving it is active on every rehearsal and production run.
Chapter 1's T-offset timeline tells you when each wave runs. The state matrix tells you, for each object class, what a user or an integration can actually do with it in each system at each stage — the two views are complementary, not competing.
Chapter 1's eight waves define what loads and in what dependency order. What this chapter adds is the gate mechanics that close each wave before the next may open: a completion check (did every entity in the wave finish loading), a reconciliation check against an agreed tolerance, a named sign-off appropriate to the object class, and an…
Chapter 1 already establishes the four-corner principle and its tolerances. This section adds the specific artefact compared on each side — the detail a reconciliation team actually works from during cutover weekend.
Chapter 1 already explains what each of the three mock cutovers demonstrates. What follows is the entry and exit criteria that make each test level a formal gate rather than an informal milestone:
A per-wave gate requires gate_status=PASS for every concept in that wave, DMF rejects = 0, no unresolved Severity-1 defects, FlexiField partition status = VERIFIED, and engine-lead sign-off.
Underneath the programme's stages and waves sits an engine, and underneath the cutover weekend's clock sits an object-by-object state change. Both need the same discipline: govern the mapping, harden the engine, gate every wave, and exit hypercare on evidence rather than a date.