How to Write a Rollback Plan for an IT Release

The reverse sequence, the triggers that start it, the point after which it is no longer possible, and the person allowed to make the call.

A rollback plan is the documented sequence for returning systems, data and business processes to their pre-release state if a cutover cannot be completed successfully. It sets out the reverse tasks with owners and durations, the conditions that trigger it, and the point in the cutover after which rollback is no longer possible.

Nearly every first cutover plan contains a rollback section. Far fewer contain a rollback plan, because a paragraph describing the intention to restore from backup is not a plan — it is a hope with a heading.

The four things a rollback plan must contain

1. The reverse sequence, with durations

Every step needed to get back, in order, with an owner and an estimated duration. Restore steps, configuration reversals, interface re-pointing, batch job reinstatement, and the business process steps — telling users to go back to the old system is a task, and it takes time.

The durations matter more than the tasks. Their sum is what determines the point of no return, and a rollback plan without durations cannot tell you whether there is still time.

2. Rollback triggers

Written in advance, in the same language as the go/no-go criteria: specific, observable conditions. For example: reconciliation variance above an agreed tolerance; a critical interface failing verification after a defined number of retries; the cutover running beyond a stated time on the timeline.

Triggers written in advance protect the person who has to invoke them at 3am, because the decision has already been argued through by people who were awake.

3. The point of no return

The moment after which rollback ceases to be viable — usually because the business has started transacting in the new system, or because the remaining window is shorter than the rollback duration.

Mark it explicitly on the cutover timeline as a dated, timed row, and derive it: window end, minus rollback duration, minus a contingency margin, minus the time needed to verify the rollback worked. Then state the decision deadline that sits before it.

4. Who decides, and on what authority

One named person, with a deputy, holding explicit authority to invoke rollback without seeking further approval. This is the clause that is most often missing and most often needed. Escalation paths are usually documented upward; the person watching the numbers at 2am needs authority to halt, or they will wait for someone senior to wake up.

Verification: rolling back is not the same as being back

A rollback plan that ends at “restore complete” is unfinished. Add the checks that confirm the old state is genuinely working: smoke tests, a reconciliation of the restored data, confirmation that interfaces are flowing again, and a business confirmation that users can transact.

Include the comms too — users, the service desk, external parties and the steering committee all need telling, and the message should be pre-written. Writing it under pressure produces bad wording.

Documented rollback is not tested rollback

If you have never executed the rollback, you do not know how long it takes. Duration is precisely what you need to know at the point of no return, which makes an untested rollback plan unreliable at the one moment it matters.

Rehearse it in a non-production environment, time it, and update the durations with what you measured rather than what you estimated. The same applies to backups: everyone takes the backup, far fewer confirm it restores. An untested backup is a belief, not a control.

Partial rollback

Full rollback is often not the only option, and thinking about it in advance is worthwhile. Can one interface be reverted while the rest stays live? Can a subset of users be moved back? Partial options are usually more attractive at 4am than a total reversal, and they are much harder to invent on the spot.

If partial rollback is viable, write it as a separate short sequence with its own trigger conditions. If it is not viable, say so explicitly — that statement is itself useful, because it removes an argument from the night.

Common mistakes

A rollback plan with no timings. Unusable at the decision point.

Assuming data can always be restored. If the business has transacted in the new system, a restore loses that work. The plan needs to say what happens to it.

Forgetting the third parties. If a partner system has already received data in the new format, rolling back your system does not roll back theirs.

Keeping it in a separate file. During the window nobody should be hunting through email at 3am. The rollback sequence belongs alongside the runsheet in the same workbook.