The mechanics of go-live weekend and the weeks after it: a real cutover-state matrix per object class, the freeze calendar and hour-by-hour runbook, the four-corner reconciliation mapped to real M3 programme families, the FAM-function reconciliation problem in its cutover-specific form, multi-company sequencing, rollback criteria, the test and validation ladder, RACI governance, and a staffed hypercare model with defined exit criteria.
Everything in the previous chapter — the extractor, the canonical model, the transformation matrix, the loader, the reconciler — exists to serve one weekend, or one sequence of weekends: cutover.
Before anything else, every object class needs an agreed answer to a simple question: what state is it in, in each system, at each stage? Ambiguity here — "I thought orders were still open in M3" — is one of the most common causes of a cutover-weekend surprise.
The freeze calendar publishes, well in advance, exactly which object class freezes at which moment — not one single "freeze everything" instant, since master data, transactional documents and financial periods each need a different freeze duration.
Each wave defined in the programme's wave plan closes only when it passes its reconciliation gate — never on a schedule alone. A gate has exactly three outcomes: pass (proceed to the next wave), conditional pass (proceed, with a documented, time-boxed exception and a named owner for closing it), or fail (the wave does not proceed;
The four-corner reconciliation compares every figure across four pipeline states — M3 source, silver, gold and post-load F&O — per legal entity, before a financial wave closes. Each reconciliation below names a real M3 programme family on one side and a real D365 report on the other:
The reconciliations above prove that balances loaded correctly. None of them, on their own, prove that the rule which will produce the next balance is configured correctly — and that gap is exactly the FAM-function hazard the previous chapter introduced, restated here as a specific pre-cutover test rather than a warning.
A CONO maps, for cutover purposes, onto a D365 legal entity — the atomic unit most programmes use to decide "does this go live now, or in a later wave" — and DIVI maps onto the operating unit, site or financial dimension that scopes activity within it. Sequencing consequences follow directly from that mapping:
Rollback criteria are numeric and agreed in advance, never decided in the room: for example, more than a defined number of critical accounts outside tolerance, an extract volume deviating from the expected range by more than an agreed percentage, or an open defect above an agreed severity threshold.
A RACI table keeps every gate decision attributable to a role, not a personality:
Cutover is where every earlier decision — the wave plan, the canonical model, the transformation matrix's governance, the operational hardening register — gets tested against a clock and a set of real numbers that either tie out or do not.