Rollback vs Roll-Forward: Which Recovery Route to Plan For
Rollback returns the system to the state it was in before the release, using a tested reverse sequence and a restore point. Roll-forward keeps the new state and repairs the fault with a fix applied on top. Rollback is normally a decision taken inside the cutover window; roll-forward is what happens once the window has closed and data has been written.
Side by side
Both are recovery routes from the same situation: something is wrong after a release. They differ in direction, in what they cost, and above all in whether the data written since cutover can survive the decision.
| Aspect | Rollback | Roll-forward |
|---|---|---|
| Direction | Return to the previous known state | Stay on the new state and repair it |
| What is restored | Code, configuration and data as they were | Nothing; the defect is fixed in place |
| Usual decision point | Inside the cutover window, before business use | After the window, once transactions exist |
| Data created since cutover | Must be preserved, reconciled or knowingly discarded | Retained |
| Time cost | Known in advance if the sequence has been rehearsed | Unknown; depends on the defect |
| Business impact | Back on the old process; the change is undone | Degraded service until the fix lands |
| Prerequisites | Tested reverse sequence, restore point, named authority | Support capacity, a release route, an emergency change path |
| Point of no return | Explicit; after it, rollback is off the table | Not applicable |
| Who decides | The authority named in the runbook | Incident and change management |
| Rehearsal | Should be tested during a dry run | Rarely rehearsed as such |
When you need rollback
Rollback is the route you plan for the cutover window itself. Something in the sequence fails, the verification checks do not pass, or a dependency does not come back up — and the business needs to be open on Monday whether or not the new system is ready.
Three things make a rollback plan real rather than decorative. First, a reverse sequence with timings and owners, at the same level of detail as the forward sequence, because reversing is not simply undoing in the opposite order — interfaces, batch jobs and downstream systems need their own steps. Second, triggers written before the weekend: the specific conditions under which rollback is called, agreed while everyone is calm rather than at three in the morning. Third, a point of no return, with a time against it.
That last one is the item most often missing. After a certain step — usually the first irreversible data change, or the moment the business starts transacting — restoring the previous state either destroys work or costs more than fixing forward. Naming that step converts an implicit assumption into a decision the sponsor has seen. Our rollback plan template is structured around those three elements, and the guide on writing one covers what each step needs to contain.
When you need roll-forward
Roll-forward is what you are actually doing most of the time, whether or not anybody uses the term. Once the business has been live for a day and real transactions exist, going back means either losing that data or reconciling it manually into the old system — and manual reconciliation of a day's trading is usually worse than the defect.
Planning for roll-forward looks different from planning a rollback. There is no sequence to write, because the fix does not exist yet. What you plan instead is capacity and route: who is available to diagnose, how a fix gets built and tested under time pressure, how an emergency change is approved, and how quickly a release can reach production. If your normal release process takes two weeks, that is the number that matters after go-live, not the theoretical one.
The other half is business continuity while the fault persists. A documented workaround, a manual process for the affected transactions, and clear communication to the people using it. Most roll-forward recoveries are survived by the workaround rather than the fix. That capability is precisely what a properly staffed hypercare period provides, and it is why hypercare staffing should be agreed before go-live rather than after.
When you need both
Every release of consequence needs both planned, because the answer changes as the weekend progresses. Early in the window, rollback is cheap and fixing forward is risky. Late in the window, and certainly after business use begins, that reverses.
The practical way to hold both is a single timeline with the switch marked on it. The runbook carries the forward sequence, the verification checkpoints, and against each checkpoint the recovery route that applies at that point. Before the point of no return, the answer is rollback and here is the sequence. After it, the answer is fix forward and here is the escalation path. The go/no-go decision then has something concrete to reference. Our cutover runbook holds both routes against the same timeline, and the go/no-go checklist records who confirmed each readiness criterion beforehand.
Both also need rehearsing, at least on paper. A dry run that exercises only the forward sequence proves half the plan. Walking the rollback steps at least once — ideally executing them in a non-production environment — is what turns an estimated four-hour restore into a measured one.
The overlap
The two are not as cleanly separated as the vocabulary suggests. Partial rollback is common: one interface reverted, one component redeployed, the rest of the release left in place. Whether that counts as rolling back or fixing forward is a matter of naming, not substance. Blue-green and feature-flag deployments blur it further — switching traffic back to the previous environment is a rollback in effect and an ordinary operation in mechanics.
They also share most of their prerequisites. Both need monitoring good enough to detect the problem quickly. Both need a named person with authority to decide, out of hours, without convening a committee. Both need a communication plan for the business, because the worst outcome of either route is users discovering the situation on their own. Both need the state of the data understood at the moment of the decision.
So the honest framing is not which strategy to choose, but at what point the cheaper option changes and who is watching for it. Teams that plan only rollback tend to be unprepared for the week after go-live. Teams that plan only roll-forward tend to discover during the window that there is no way back. The cutover plan is where both belong, and the plan-versus-runbook distinction explains which document carries which level of detail.
Questions
Is roll-forward the same as fixing forward?
Yes, the terms are used interchangeably. Both mean keeping the new state in place and resolving the fault with a subsequent fix rather than reverting the release.
What is the point of no return?
The step in a cutover after which returning to the previous state would destroy work or cost more than fixing forward. It is usually the first irreversible data change or the moment the business begins transacting.
Should rollback be tested?
It should be walked through at minimum, and executed in a non-production environment where possible. An untested reverse sequence gives you an estimate rather than a duration you can rely on.
Who decides to roll back?
A single named authority in the runbook, with a deputy. Rollback decisions are taken under time pressure and often out of hours, so a decision that requires assembling a group is a decision that arrives late.
What happens to data entered after cutover if you roll back?
It has to be preserved, reconciled into the old system, or knowingly discarded. Deciding which in advance, per data type, is what makes a late rollback possible at all.