Comparisons
Pairs that get conflated in real conversations, and a few that get treated as synonyms when one is a prerequisite for the other. Neither column wins — what decides is the change in front of you. Each record leads with the confusion, because the confusion is why the record exists.
Rollback vs Roll-Forward
Rollback is taught as always-correct, so teams assume it is available and discover during the incident that it is not. It is a data question, not a deploy question: once the new version has written data the old version cannot read, going back is a second outage. The mirror mistake is "we always roll forward", which usually means writing code under time pressure with no verification — the highest-risk activity in this domain. Neither is the default; the honest answer is that rollback should be the default and you must engineer to keep it available.
Use rollback when the previous artifact is known good, still compatible with current data and dependencies, and returning to it stops user impact.
Use roll-forward when going back is impossible or unsafe — an irreversible migration, data written in the new shape, a dependency that has already moved — or when the fix is small, understood and verifiable.
| Dimension | Rollback | Roll-forward |
|---|---|---|
| Restores | A previously verified artifact | A newly written, unverified one |
| Time to safety | One deploy, if it is available | Fix, review, build, test, deploy |
| Blocked by | Irreversible migrations, new-shape data, dependency versions that moved | Not understanding the failure yet |
| Risk | Reintroducing whatever the new version fixed | Shipping a second defect on top of the first |
| What keeps it available | Expand/migrate/contract, backward compatibility, artifact retention | A fast pipeline and strong automated verification |
| Best answer under time pressure | Usually this, if it exists | When the above is genuinely not an option |