Cutover day: the runbook that keeps a migration boring

The best compliment a cutover can get is “nothing happened.” That outcome isn’t luck — it’s what a well-built runbook is specifically designed to produce, by removing every decision that would otherwise have to be made live, under pressure, on the day itself.

What belongs in the runbook

A real cutover runbook is a step-by-step sequence with explicit owners, explicit go/no-go checkpoints, and explicit rollback triggers defined in advance — not “monitor closely and use judgment.” Every step should have a clear success criterion, so the person running it doesn’t have to interpret whether something looks fine; they just check whether it matches what was specified.

Go/no-go checkpoints, not one big decision

Instead of a single go/no-go call at the start, the runbook breaks cutover into checkpoints, each with its own criteria to proceed. That turns one high-stakes decision into a series of smaller, reversible ones — and means the team can stop safely at any checkpoint instead of being committed the moment the process starts.

Rehearsal matters more than the document

A runbook that’s only ever existed on paper will surface gaps exactly when you can least afford them. Running a full dry rehearsal — ideally against a realistic staging environment — is what turns a runbook from a plan into something the team has actually executed before, which is the difference between confidence and hope on the real day.

Why boring is the actual goal

A tense cutover is a sign that decisions are being made live that should have been made in advance. The measure of a good runbook isn’t how impressive it looks — it’s how uneventful the day turns out to be, because everything that could have been a surprise was already accounted for. This is the kind of work described in what a legacy migration specialist actually does.