The underestimation problem
S/4HANA programs over-invest their attention where the intellectual interest is: Fit-to-Standard design, custom-code remediation, testing. Cutover gets a runbook, a weekend, and a prayer. Then the live window arrives and the program discovers — at the worst possible moment — a sequencing dependency nobody had walked, a data load that reconciles badly, an interface that starts in the wrong order. None of these are exotic failures. They are exactly the class of defect that rehearsal exists to find, which is why the honest framing of cutover is not logistics but an evidence discipline: the rehearsal results and reconciliation proofs are the artifacts that authorize go-live.
Where cutover lives in the method
In SAP Activate terms, cutover is not a weekend — it spans two phases. The plan and the rehearsals are built and run late in Realize, and the Deploy phase deliverables explicitly include dress rehearsal, production cutover, go-live, hypercare support, and handover to the support organization. That deliverable list is worth reading twice: SAP’s own method treats the rehearsal as a first-class deliverable, peer to the production cutover itself — not as an optional confidence-builder to be cut when the schedule compresses.
The dress rehearsal is the core control
SAP’s guidance on the mock cutover is specific about intent: the dress rehearsal should test all aspects of the cutover prior to production, emulating the production cutover as closely as possible — plan, processes, logistics, resources, and IT environments — and should include everything planned for go-live, “even a late bug fix”. Track each rehearsal for completeness and elapsed time; both numbers are evidence. Completeness tells you whether the runbook describes reality; elapsed time tells you whether the plan fits the window.
One honesty note the industry rarely offers: SAP does not prescribe how many rehearsals to run. Practitioner guidance you will encounter — run two mocks, one at partial and one at full scope — is a reasonable framework, but it is judgment, not a standard. The correct number for your program is the number after which a full rehearsal completes inside the window with no unresolved gaps. That is an exit criterion, not a count.
Minimized-downtime options — and their fine print
For system conversions where the downtime window is the binding constraint, SAP offers technical options beyond the standard approach: near-Zero Downtime Maintenance (nZDM) and downtime-optimized conversion, which move data conversion and, where required, database migration into the uptime processing of the Software Update Manager. The mechanism is elegant: shadow fields are filled via batch jobs during uptime, while database triggers capture the deltas from parallel production activity for later replay; the benefit SAP claims is, in its own words, reduced downtime — SAP publishes no specific percentage or hour figure, and neither should anyone else before rehearsing on your landscape.
The fine print materially changes the plan, and it is rarely surfaced in thought-leadership: SAP designates the downtime-optimized approach as restricted — “for educated experts only,” requiring a completed assessment and a password requested via SAP support ticket, imposing a customizing freeze and a lock on development activities in production before downtime, and requiring that mass-load activities be avoided during the replication phase. SAP is equally plain that project planning is more complex than the standard approach. In other words: you can buy a smaller downtime window, and you pay for it in planning complexity, freeze discipline, and expertise gating. Sometimes that trade is right. It should be made consciously, in the cutover strategy, months before the weekend.
Freeze, sequencing, and the command center
Around the technical core sits the governance that practitioner experience consistently identifies: a dependency-driven cutover plan with timing, ownership, dependencies, parallel activities and buffers; dry runs to discover the gaps before go-live; a command center with clear roles and escalation; and business-team preparation running into hypercare. The unglamorous details decide outcomes here: when the customizing freeze starts and what it exempts; the transport sequence; which interfaces stop when, and who owns restarting them; how the legacy shutdown is coordinated so nothing writes to the old system after the extract.
Reconciliation is the go-live gate
Data migration is not done when the load finishes; it is done when it reconciles. A practical framework — attributed here as practitioner method, not SAP standard — sequences strategy, preparation of the runbook and scripts, full-scale simulation, execution with validation of row counts and referential integrity, and hypercare to defined exit criteria. For a finance-bearing system, reconciliation means sub-ledger-to-GL agreement and opening-balance proof, with exception thresholds agreed in advance. Be careful with the numbers you will find in circulation: specific variance thresholds are practitioner heuristics, not published standards, and the right thresholds are the ones your finance leadership signs, in writing, before the weekend. The principle, though, is not negotiable: the reconciliation pack is the evidence that authorizes go-live, and if it does not exist, the go/no-go meeting is being asked to approve on faith.
Go/no-go and rollback, specified for use under pressure
The go/no-go discipline should be written the way pilots write checklists: named decision-makers; sequenced tasks with owners; data-load reconciliation and exception thresholds; interface stop/start timing with monitoring ownership; a fallback process for critical operations; and rollback criteria “specific enough to use under pressure”. That last phrase deserves emphasis. A rollback criterion of “significant issues” is useless at 03:00 on Sunday; “reconciliation exception class X unresolved at hard-stop time Y” is usable. If the downtime-optimized path is in play, remember the standard DMO design retains the source database, giving a defined reset path — but the reset decision, too, needs a named owner and a hard-stop time.
Hypercare: the window where data tells the truth
Hypercare is the short, intensive-support window immediately after go-live in which the new system is stabilized — and where subtle data-integrity issues that survived testing are often first surfaced by the business users who know the data best. Staff it accordingly: the people who built the loads should be reachable by the people fielding the tickets. And define the exit before you enter — SAP does not mandate a hypercare duration, so the honest exit criterion is stability evidence (incident rates, reconciliation cleanliness) sustained over an agreed period, not a date on a calendar.
The honest checklist
What to rehearse: the entire runbook, at production scale, including the late bug fix. What to reconcile: row counts, referential integrity, sub-ledger to GL, opening balances — against thresholds finance signed beforehand. What to decide in advance: freeze scope, interface sequencing, go/no-go owners, rollback criteria, hypercare exit evidence. And what to refuse: any downtime hour-count, mock-run count, or hypercare week-count presented as an industry benchmark. Those numbers are program-specific. The discipline is not.
Go-live authorization should be a verdict rendered on evidence — rehearsal results and reconciliation proofs — not a date defended by optimism. Programs that treat cutover as an evidence discipline get boring cutover weekends. In this workstream, boring is the win condition.