Cutover weekend, reconciliation and hypercare

The hour-by-hour mechanics of go-live weekend — what freezes and when, the reconciliation gate that closes each wave, four-corner financial reconciliation report by report, what rollback actually means once the first customer invoice posts, and the governance and hypercare model that carries the programme from go/no-go to handover to run.

What you will be able to do

• Read and build a cutover-state matrix showing what is open, closed or frozen at every stage
• Explain the hour-by-hour runbook shape from SAP freeze through hypercare exit
• Name the four corners of financial reconciliation and the specific SAP report paired with each D365 report
• State precisely what rollback means before, during and after the blackout window — and why it stops meaning that after go-live
• Distinguish unit, integration, UAT, mock-cutover and regression testing by what each one actually proves
• Read a RACI matrix and a hypercare severity ladder and apply both to a live defect

Introduction

Chapter 2 covered the engine that moves the data. This chapter covers the weekend it moves it for real: the state everything is in before, during and after the blackout window, the specific reports that prove the numbers agree, what "rollback" actually means once real transactions exist only in the new system, and the governance and…

The cutover-state matrix

Before anything else, cutover planning has to answer a deceptively simple question for every object class: at each stage, is SAP open for transactions, closed to users but still readable, or fully frozen — and is D365 not yet live, mid-load, or live?

The freeze calendar, the hour-by-hour runbook and the wave gates

The blackout window — SAP locked, D365 not yet live — runs approximately 24 hours for a mid-size organisation, and that number is communicated to the business at T-7 days. It is not a fixed constant: GL opening balances alone can take up to 180 minutes per the wave manifest, and a higher-volume financial entity can extend the window…

Four-corner reconciliation, tolerances and the evidence pack

"Four-corner" reconciliation means proving the same financial truth from four independent angles — the AR, AP, inventory and fixed-asset subledgers — each tied back to the general-ledger trial balance that anchors them. Every corner pairs a named SAP report on one side with its D365 equivalent on the other:

Rollback: decision criteria, the point of no return and restart semantics

If a No-Go is called at T+24h, rollback is a defined, seven-step procedure, not an improvisation: trigger the abort_run kill switch in the engine's control plane; unlock SAP business users, reversing the SU01 lock;

Test and validation strategy: from unit tests to mock cutover three

Each layer of testing exists to catch a defect class the layer above and below it cannot:

Governance: RACI, steering cadence and gate criteria

Five roles carry the programme: the Programme Manager owns overall timeline, budget and escalation; the ERP Architect owns technical design, architecture sign-off and canonical model governance; the Data Migration Lead owns wave execution, the extraction pipeline and reconciliation-gate management;

Hypercare: staffing, triage, severity and the handover to run

Hypercare begins at T+48h, once the go/no-go decision has cleared and end users have had a working day on the new system, and runs for thirty days with a daily drift-dashboard review throughout.

Knowledge check

Summary

A cutover weekend that works is the product of an explicit state matrix, gates that are binary and named rather than felt, and a governance model that never lets "the team that did it" also be "the team that approved it."