It's 2am and the totals don't match. Nobody agreed who can call a rollback.

Most cutover plans are very detailed about moving the data. Hour by hour, step by step, who runs which script. They're much vaguer about what happens when the data doesn't reconcile. So at 2am, a tired group on a call debates it from scratch. Is this break small enough? Who decides? Can we still go back?

Those are hard questions to answer well at 2am. They're much easier on a Tuesday afternoon. So before the weekend, I want 4 things in writing.

1. What blocks go-live

Which breaks stop the cutover, and which can be fixed after. Decide it while everyone is calm.

For example: a difference in the general ledger balance blocks go-live. A difference in a customer's preferred contact method doesn't. Somewhere between those two are the hard cases, and it's worth spending time on them in advance. A useful format is a short list of checks, each with a threshold and a label: "blocking" or "fix after go-live".

Without this, the threshold gets set on the night, under pressure, by whoever argues most confidently. And the pressure always points the same way: go live, we've come this far.

2. One name who makes the call

Not "the steering group". A person, with a phone number, who is awake.

Groups are good at discussing and bad at deciding at 2am. The decider should have the authority to say no, should know the criteria from point 1, and should be reachable during the window. Name a deputy too, because people do fall asleep or lose signal.

3. The point of no return

The moment new transactions start landing in the new system, rollback stops being simple. Payments get taken, orders get placed, users update records. Going back now means either losing that activity or replaying it into the old system, and neither is pleasant.

Know when that moment is, and put it in the plan. The go/no-go decision has to happen before it, with enough time to actually roll back if the answer is no. If the plan doesn't leave that time, the decision isn't real.

4. A rollback you have actually tried

Most teams rehearse the load in the mock run. Very few rehearse going back.

A rollback plan that has never been run is a hypothesis. Restoring backups takes longer than expected. Someone's access was removed from the old system as part of decommissioning prep. The interface that was switched off doesn't come back cleanly. Run it once, in the mock, and time it. Then you know whether it fits inside the window before the point of no return.

None of this is technical

That's the interesting part. The data load is usually well tested by the engineers who built it. The weak spot is the decision around it: the criteria, the person, the timing, and the escape route.

It's also the part that decides whether Monday is calm or a blame meeting. If the criteria were agreed and the decider followed them, a rollback is a normal outcome, not a failure. If nothing was agreed, every option on the night looks like someone's mistake.

A trade-off worth naming

Writing strict criteria can feel like setting the project up to fail. Teams worry that a hard threshold will force a rollback over something minor. That's a fair concern, and the answer is to spend the time getting the thresholds right, not to leave them vague. Vague criteria don't remove the risk. They move the decision to the worst possible moment.

In short

  • Agree which breaks block go-live.
  • Name one decider, plus a deputy.
  • Know the point of no return.
  • Rehearse the rollback, and time it.

On your last cutover, was the go/no-go decided before the weekend or on the call?