The engine from chapter 2 executes inside a real calendar: a freeze that starts days before go-dark, a roughly 24-hour window in which eight waves load and reconcile, and a hypercare period that decides whether the migration actually succeeded. This chapter works through the cutover-state matrix, the hour-by-hour runbook, four-corner reconciliation in detail, the SLA reconciliation problem, rollback criteria, test strategy, RACI governance and hypercare exit criteria.
Chapter 2 opened the migration engine itself — the extractor, the canonical model, the loader, the fifteen-dimension hardening register. This chapter puts that engine inside the calendar it actually runs in: a freeze that begins days before anyone touches a keyboard on cutover day, a roughly 24-hour window in which eight waves load and…
At every point in the window, every object class in the business is in exactly one of a small number of states — open, frozen, loading, or live — in each of the two systems. Naming this explicitly, for every object class, is what keeps a 24-hour cutover from turning into an argument about what is safe to touch.
The blackout window is simple to state and easy to under-plan for: Fusion is read-only from T-0 until the end of the programme — it does not reopen after go-live, other than for audit reference — and F&O is read-only from T-0 until T+23h, opening only once reconciliation is green and sign-off is captured.
Four-corner reconciliation is the contract that decides whether the cutover actually worked, and it compares exactly four views:
The cutover window is where the SLA translation described in the posting-engine module is tested under fire. Every posting-profile configuration, every default-dimension assignment, every account-structure rule is exercised for the first time against real transaction volume when Wave 6 and Wave 7 post.
Every recon gate in this chapter runs against a tolerance and produces evidence, and both are explicit rather than implied.
The programme's test strategy runs in layers, from engine-owned automated testing through to customer-owned business validation, each with its own entry and exit criteria.
Governance during cutover runs on a RACI that names a single accountable owner for every workstream, with the programme sponsor holding ultimate escalation across all of them:
A cutover-state matrix names, for every object class, exactly what state it is in — open, frozen, loading or live — in both Fusion and D365, at every stage; freeze points are staggered by how long each object class's in-flight state takes to settle. Fusion goes read-only permanently at T-0;