Cutover Runbook¶
Operational artifact — instantiates Controlled Phase Transition
Scripts the concentrated switch as timed actions, owners, checks, and go/no-go gates so a high-risk cutover executes the way it was rehearsed.
A Cutover Runbook is the minute-by-minute script for a concentrated crossing — the case where the transition is not spread across weeks but compressed into a single planned window and everyone flips at once. Its defining idea is the rehearsed, gated switch: the whole crossing is written down in advance as an ordered list of timed actions, each with a named owner, an explicit verification check, and go/no-go decision gates at the points of no return, so that on the night itself no one is improvising. Where a phased crossing buys safety through time, a cutover buys it through preparation — the runbook is the artifact that makes a fast switch survivable by removing every question that could be answered beforehand.
Example¶
A retail bank is replacing its decades-old core banking system over a single weekend. There is no way to run the two cores gradually against live customer accounts, so the crossing is a concentrated cutover: Friday 22:00 the old core is frozen, and by Monday 06:00 the new one must be serving ATMs, cards, and branches. The Cutover Runbook is a 140-step document. It opens by pinning the exact from-state — which software versions are live, which batch jobs must have completed, the precise balance snapshot to migrate — because the switch is only reversible relative to a known baseline. Each step has a time offset (T+0, T+45m), an owner (data lead, network lead, card-scheme liaison), and a check that must pass before the next begins. Two gates are marked in red: a go/no-go at T+3h after data migration ("proceed only if reconciliation matches to the penny"), and a point-of-no-return once card traffic is repointed. Because it was rehearsed twice on a copy, the live run has no surprises the runbook did not already answer.
How it works¶
- Pin the start-state precisely. Enumerate the exact configuration, versions, data snapshot, and dependencies the switch departs from — the switch is only well-defined against a frozen baseline.
- Sequence every action with a time offset and an owner. No step is unassigned; no step floats without a place in the timeline.
- Attach a verification check to each step. A step is not "done" because it ran, but because its check passed.
- Mark the decision gates and the point of no return. Explicit go/no-go criteria sit at the moments where continuing forecloses retreat.
- Rehearse it. The runbook is validated by a dry run on a copy, which is what converts a plan into a script.
Tuning parameters¶
- Step granularity — fine-grained steps catch more, coordinate tighter, but bloat the document and slow the window; coarse steps move fast but hide failure points.
- Window length — a short window limits exposure and customer impact but leaves no slack for trouble; a long one is safer per-step but extends the risky interval.
- Gate strictness — how unambiguous and binding each go/no-go check is. Sharp gates prevent "push on regardless" but can halt a switch on a technicality.
- Rehearsal fidelity — how closely the dry run mirrors production. Higher fidelity surfaces more, at real cost to build a faithful copy.
- Contingency depth — how many steps carry an inline "if this check fails, do X" branch before the crossing hands off to a separate rollback plan.
When it helps, and when it misleads¶
Its strength is that it turns a terrifying one-shot switch into something executed, not attempted: a runbook makes a concentrated cutover repeatable, auditable, and rehearsable, and its gates give the team explicit permission to stop at a point of no return[n1] rather than discovering it too late.
Its failure mode is the calendar-driven cutover — the date is fixed, the checks are treated as formalities, and the go gate is waved through because stopping is politically unthinkable. A runbook whose gates cannot actually say "no" is theater. It also fails when the pinned start-state has drifted since rehearsal, so the live system no longer matches the script. The discipline is to keep the gates binding and owned by someone empowered to halt, and to re-verify the baseline immediately before the window — a runbook is only as trustworthy as its last honest check.
How it implements the components¶
cutover_criterion— the runbook's go/no-go gates are the crossing's cutover criteria: the explicit, checked conditions under which the switch proceeds, pauses, or is declared complete.start_regime_definition— it pins the exact operational from-state (versions, data snapshot, dependencies, freeze point) the switch departs from, so the crossing is defined against a known baseline.
It does not sequence a gradual, wave-by-wave crossing (staging_rule — that's Phased Rollout), define how to undo the switch once it has failed (fallback_or_rollback_policy — that's Rollback Playbook), or run the two regimes concurrently to preserve a live fallback (parallel_operation_window — that's Parallel Run).
Related¶
- Instantiates: Controlled Phase Transition — the artifact that executes a concentrated crossing as a rehearsed, gated switch.
- Consumes: Transition Readiness Review supplies the pre-window go decision that authorizes running the runbook at all.
- Sibling mechanisms: Canary or Pilot Transition · Phased Rollout · Parallel Run · Rollback Playbook · Stabilization Period · Transition Readiness Review · Transition War Room · Migration Wave Plan
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Cutover Runbook operates as a repeatable ordered procedure or handoff sequence that coordinates action because it scripts the concentrated switch as timed actions, owners, checks, and go/no-go gates so a high-risk cutover executes the way it was rehearsed.
Independent corroboration: The frozen evidence defines Cutover Runbook as 'Scripts the concentrated switch as timed actions, owners, checks, and go/no-go gates so a high-risk cutover executes the way it was rehearsed', so its operative form is Protocol, Workflow & Routine.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: IT operations cohered cutover runbooks as rehearsed, minute-by-minute scripts with named owners, verification checks, rollback conditions, and go/no-go gates for concentrated system migration.
Related originating lineages:
- Engineering & Design — Commissioning and operational engineering supplied staged verification and points-of-no-return control for physical transitions.
- Organizational & Management Science — Operational change management supplied command roles, readiness reviews, and coordinated execution across participating units.
Review resolution: IT operations cohered cutover runbooks as rehearsed, minute-by-minute scripts with named owners, verification checks, rollback conditions, and go/no-go gates for concentrated system migration.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The runbook and the rollback plan are deliberately separate documents. The runbook drives the crossing forward and marks where retreat ends; Rollback Playbook owns the return path once a gate says no. Folding the abort branch into the forward script tempts a team to skim past it under time pressure — which is exactly when the return path matters most.
[n1] A point of no return is the moment in an operation past which reversing costs more than completing, or is impossible. Naming it in advance is what lets a go/no-go gate be placed before it rather than discovered after. ↩