Cutover: the abort point and the rollback boundary
Two distinct concepts that cutover plans routinely conflate.
Before cutover, agree the change window, source controls, communications, decision makers and the evidence each decision will be based on.
Two distinct concepts govern the window, and cutover plans routinely conflate them.
The rollback boundary is the point beyond which returning to the source is no longer safe or practical. It is reached when the target accepts business writes, when downstream systems switch permanently, or when the source no longer holds a consistent recovery position. Most plans describe rollback as though it is available throughout. It is not. Name the boundary explicitly, name the person authorised to cross it, and make crossing it a decision someone consciously takes rather than something that happens because the clock moved.
The abort point is different, earlier, and more useful. It is the latest moment at which you can stop and still restore normal service in time. It is not derived from the migration plan at all. It is calculated backwards from the business requirement: service must be available Monday at nine, rewind takes this long, verification takes this long, contingency is this much — therefore the decision has to be made by a specific hour on Sunday, and if the migration has not reached a defined milestone by then, it stops.
Setting it, and holding it
I once oversaw a weekend cutover governed by exactly that structure: a defined milestone by 2pm Sunday, or abandon and rewind so the business opened normally on Monday. I called the abort twice, which made me deeply unpopular with the migration and development teams. The third attempt, a month later, went smoothly. Field note: The weekend I called abort twice
Some things that experience taught me.
Set the abort point in cold blood, and put a milestone against it. Decided in advance, with the business, it is arithmetic. Decided at 2pm on the Sunday, it is an argument — one you will lose, because everyone in the room has been awake for eighteen hours, is deeply invested, and can construct a plausible account of how the lost time will be recovered. A time alone is not enough: pair it with an objective, checkable milestone, so the question at 2pm is “have we reached this point?” rather than “do we think we can finish?”
Nobody thanks you for the disaster that did not happen. This is the hard part. When you abort, the cost is immediate, visible and attributable to you — a wasted weekend, an unhappy team, a slipped date. The catastrophe you prevented is invisible and unprovable, because it never occurred. You will never receive credit for it and you should not expect to. Do it anyway.
Give the authority to one named person and make it non-negotiable in advance. The decision cannot be made by consensus at the moment it is needed, because at that moment the people best placed to judge are the people least able to be objective. Agree who holds the call, agree that it is theirs alone, and get that agreed by someone senior enough that it cannot be relitigated in the room at 2am.
Two aborts are not two failures. They are the control working exactly as designed. And the third attempt went smoothly in part because of the first two — each aborted run is a full-scale rehearsal on production, and the team came back knowing precisely where the time was going. Plan the re-attempt cadence in advance rather than treating it as an unplanned recovery: how long to diagnose, fix and re-approve, and when the next window is.
Rewind has to be rehearsed and timed, not assumed. The abort point is arithmetic, and one of its terms is the rewind duration. If that number is an estimate, your abort point is an estimate too, and you will discover the error at the worst possible moment. Time the rewind during rehearsal, as a rehearsal objective in its own right.
For the rollback path itself, document how the source will be preserved, how any writes already taken on the target will be handled, who is told, the recovery sequence, and the latest safe time to make the call.
Use the cutover and rollback template during rehearsal, and update it with measured timings before the live run.