The cutover-state matrix, the T-72h to T+24h freeze calendar and runbook, the reconciliation gate that closes each wave, four-corner reconciliation against real LN sessions and D365 reports, project-driven reconciliation, rollback and restart semantics, test strategy, governance RACI, and the hypercare model that carries the programme to handover.
Part 2 described the engine that moves the data. This part describes the weekend — or, more precisely, the twenty-four hours — during which that engine actually runs against a live financial system, and everything the programme does before, during and after to make that run safe: what is open, closed or frozen at each stage, the…
At any given moment during the cutover window, every object class is in exactly one of three states in each system — open for normal transaction entry, frozen (visible but not modifiable), or closed entirely — and confusion about which state applies to which object class at which moment is one of the most common sources of…
The cutover window is twenty-four hours, and every wave inside it is dependency-ordered, not calendar-scheduled — but the freeze events leading up to and inside that window are calendar-scheduled, down to the hour:
Each of the eight waves closes only when its own reconciliation gate passes, and the gate criteria are the same for every wave: reconciliation status must show a pass for every canonical concept touched by that wave, DMF rejects must be exactly zero, and there must be no unresolved Severity-1 defect outstanding against that wave.
The finance-owned four-corner reconciliation is distinct from the engine's own technical four-corner delta report described in Part 2, and both names should be used carefully so the two are never confused in a status conversation.
Project-driven reconciliation matters more in an LN migration than in most source-platform migrations, precisely because LN's project pegging links purchase orders, production orders and inventory movements directly to project activities in a way many competing ERPs do not attempt at all.
Validation runs at several layers well before cutover night: unit tests on every transform module run on every pull request; integration tests exercise each wave end to end against a synthetic LN dataset nightly; recon tests run weekly in sandbox against a frozen LN extract;
Hypercare opens at T+24h, the moment the cutover formally closes, and its staffing model deliberately mirrors the cutover team rather than handing straight to a generic help desk: the same SI support lead and migration engineering lead who ran the cutover remain engaged, reporting to the programme director, with the customer's own…
The cutover-state matrix and the T-72h to T+24h freeze calendar remove ambiguity about what is open, frozen or closed at any moment. Each wave closes only against its own reconciliation gate, and rollback has a hard, published boundary at T+22h beyond which forward-fix is the only option.