A platform must cut over a critical service. What does a cutover plan need beyond the switching steps?

What it needs beyond the steps

1. A rollback plan with a decision point and a named decision-maker. Not "we can roll back" but: at this step, if this metric exceeds this value, this person decides, and the rollback takes this long. Rollback decisions made under pressure without a pre-agreed trigger are made late, and lateness is what turns a recoverable cutover into an incident.

2. The point of no return, identified explicitly. After the new system takes writes the old one has not, rollback means losing those writes. The plan must state where that point is, what the recovery is beyond it, and who authorises crossing it.

3. A rehearsal. The full sequence executed in a realistic environment, timed. Almost every cutover plan contains a step that takes far longer than assumed, and finding that during the rehearsal rather than at 3 a.m. is the entire value.

4. Verification at each step, not only at the end. What proves that step succeeded before the next begins.

5. Communication. Who is informed, when, and what they are told — internally and to customers. Prepared beforehand, because deciding what to say during a problematic cutover is not something to improvise.

6. The people plan. Who is present, for how long, what happens if the cutover runs longer than planned, and who takes over. Cutovers that overrun are handled by exhausted people making poor decisions.

7. The recovery ramp. Traffic returned gradually to the new system, not all at once — cold caches and empty connection pools mean a system that is technically live is not yet ready for full load. Second incidents happen during recovery.

What reduces risk most

Reducing the granularity of the cutover. Per tenant, per region, per shard, per percentage of traffic. A staged cutover bounds the blast radius of every mistake and provides real evidence before proceeding.

The alternative — a single global switch — concentrates all the risk at one moment, which is precisely the shape you want to avoid for a critical service.

The question that tests the plan

"What happens if step four succeeds and step five fails?" A plan that only describes the forward sequence has not been thought through. Every step needs its failure branch, and the branches are where the plan's real content is.