The cutover hour, written down in advance

Write it as a list somebody else could run

The test of a runbook is whether a competent colleague who was not in the planning meetings can follow it. That rules out steps like switch the flag, and requires which flag, in which environment, by which command, and what the expected output looks like. It also means naming the person on each step, because a step with no owner is a step where two people either both act or both wait.

Include the checks between the actions. A cutover is not a sequence of changes, it is a sequence of change-then-verify pairs, and the verification is what gives you a defined point to stop at. Without them you find out at the end that step three failed, and the diagnosis has to unwind everything that followed it.

• Pre-flight checks, run and signed off before anything changes
• A freeze on unrelated deploys, announced with a start and an end time
• Each action with an owner, an exact command and an expected result
• A verification after every action, not one at the end
• The abort procedure, written in the same detail as the forward path

Run it in shadow before it is real

The last thing to do before cutting over is to run the new path against real traffic without depending on it. Authenticate through the new system in parallel, compare the outcome with the current one, record any disagreement, and serve the answer from the old path regardless. Mismatches surface as data instead of as incidents.

Shadow running is where you learn the unglamorous things that no test environment produces: a password manager that fills a differently named field, a customer whose directory returns an attribute nobody had seen, a mobile client caching something it should not. Each of those would have been a ticket during the cutover, and each is now a fix made on an ordinary afternoon.

Every mismatch found in shadow is an incident you did not have, discovered on a day when nothing was at stake.

One person holds the abort call

Name them before the hour begins, and let it be somebody who is not executing the steps, because the person typing is the worst placed to judge whether the whole thing is going badly. Give them explicit criteria agreed in advance: sign-in failure rate above a stated level, support volume above a stated level, any authorisation error affecting more than a named number of organisations.

Agreeing the numbers beforehand is what makes the decision possible. In the moment, everything looks recoverable, every failure has a plausible explanation, and the natural human response is to push on for another ten minutes. A threshold set in daylight by somebody who was not invested in the outcome is the only mechanism that reliably overrides that instinct.

The first ten minutes, and the two days after

In the first ten minutes, watch the rate of successful sign-ins rather than the error log. Errors tell you what broke; the success rate tells you whether people are getting in, which is the only question that matters. Have a real account on a real device and use it. Have someone watching the support inbox, because users report symptoms your dashboards do not have a metric for.

Then keep the old path capable of serving traffic for longer than feels necessary. The decision to reverse can arrive days later, from a customer whose particular configuration nobody exercised, and a rollback path that was dismantled the same afternoon is not a rollback path. Set a date to remove it, put it in the plan, and delete it deliberately rather than leaving a second authentication system running quietly for a year.

• Watch successful sign-ins per minute, not only the error rate
• Sign in yourself, on a real device, before declaring anything
• Keep the previous path serviceable past the point where it feels needed
• Schedule its removal as a dated task, and carry it out on that date