Rollback

Rollback is the unstated assumption behind every confident deployment: the ability to return to the last known-good state, quickly, when the new one misbehaves. Every release strategy is really two strategies — how to go forward, and how to get back — and it is the second one that separates calm operations from 2am war rooms.

What It Is

Rollback is the restoration of a previous working state after a failed change: redeploying the prior application version, reverting configuration, or restoring data. Its difficulty varies with what the change touched — application rollback is often minutes (prior version, already built and tested); database rollback is harder (schema changes affect data, and un-making them safely requires backward-compatible design); stateful migrations hardest of all. The engineering discipline is designing for reversibility: forward-and-backward-compatible schema changes, blue-green or canary patterns that keep the old version warm, and feature flags that 'roll back' a feature without touching the deployment at all.

Why It Matters to You

The single most diagnostic question about any delivery operation is its rollback time — measured, rehearsed, in minutes — because it prices every other risk decision. With fast rollback, a bold release cadence is prudent; without it, even cautious releases are gambles. In vendor management, the same question applies to their deployments into your environment or their SaaS: when their release breaks your workflow, what is the recovery path — their rollback, or your incident? Contracts rarely address it, which is exactly why it should be asked in due diligence and, where the system is critical, written in.

When You'll Meet It

In release planning and incident review. Ask for the last rehearsed rollback, with a timestamp — unrehearsed rollback plans have a way of not existing when needed.