Rollback Plan
A rollback plan sets out how a release or transition is reversed if it cannot be completed. It records the triggers that start it, who has authority to call it, the point after which it is no longer available, the reverse sequence with timings and owners, how data is restored, and how the return to the previous state is verified and communicated.
A rollback plan is not the deployment plan read backwards. Reversing a release usually involves different steps, different systems and a data problem that the forward path did not have — transactions entered in the new system during the window have to be dealt with, and that decision is the part most plans omit.
What it contains
| Section | What it records |
|---|---|
| Triggers | The specific conditions that put rollback on the table: a failed reconciliation, an unrecoverable interface, an overrun past a stated checkpoint |
| Decision authority | Who can call it, who must be consulted, and how long the decision itself is allowed to take |
| Point of no return | The step after which rollback is no longer available within the window, and what the recovery route is instead |
| Reverse sequence | The steps to restore the previous state, numbered, with owners and durations from a rehearsal |
| Data position | Which backup is restored, what happens to work entered since the switch, and who reconciles it |
| Interfaces and downstream | What has to be re-pointed, re-run or suppressed in connected systems |
| Verification | The checks confirming the previous state is functioning, and who signs them off |
| Communications | Who is told, in what order, with the message prepared in advance |
| Resumption | What happens next — a rescheduled attempt, a remediation plan, or a decision to be taken later |
The Rollback Plan Template (Excel) holds the reverse sequence with triggers and the point of no return as explicit fields rather than as prose.
How it is used
The plan is agreed before the window and referenced at each checkpoint in the runbook. In practice it functions as a clock: because the reverse sequence has a known duration, the latest moment at which rollback can still finish inside the window can be calculated, and that moment becomes a decision point in its own right.
Rehearsing the rollback is less common than rehearsing the cutover, and it is the difference between a plan and a document. The rollback plan guide covers the triggers and the point of no return in more detail.
Where it goes wrong
The most common failure is a rollback plan with no timings. If nobody knows whether reversing takes two hours or nine, the decision cannot be taken rationally at the point it is needed.
The second is unstated triggers, which leaves the call to judgement under fatigue at the worst hour of the night. The third is silence on data: the plan restores the system and says nothing about the transactions users entered in the two hours the new system was open. The fourth is an untested restore — backups that have never been recovered are an assumption, not a control.
The fifth is a rollback plan owned by nobody. It is written once, filed with the cutover pack and not revisited when the release scope changes, so by the time it is needed it describes a system configuration that no longer exists. Reviewing it at the same points the runbook is reviewed keeps the two consistent, and the review is short because the document is short.
Related terms
See also cutover runbook, go/no-go decision and freeze period.
Questions
What is a point of no return?
The step after which reversing is no longer practical within the available window. It is identified in advance, marked in the runbook, and treated as a decision point.
Who decides to roll back?
The person named in the cutover plan, normally the business owner or the cutover manager acting under delegated authority, against triggers agreed before the window opened.
Does a rollback plan need to be rehearsed?
Rehearsing it is what produces reliable timings, and timings are what make the decision possible. Where a full rehearsal is impractical, the restore step at least is usually tested.
What happens to data entered after the switch?
The plan has to state it: discarded, re-keyed, or held and reconciled later. Leaving it unaddressed is the most common gap in rollback documentation.