What is a rollback?
Reverting the code takes seconds. The migration it ran and the email it sent five minutes earlier already happened, and no rollback undoes either.
Rollback
A rollback is the act of returning a system to its last working version after a release causes a problem. It usually means redeploying the previous build or flipping traffic back to it, undoing the change rather than patching forward.
A team ships version 42. Within minutes, error rates climb or a feature stops working. Instead of writing a fix under pressure, someone rolls back to version 41. That was the build working an hour ago.
For application code alone, this is close to free. A previous build is already sitting in storage. A deploy pipeline built for it can point traffic back at that build in seconds. Blue-green deployment and canary releases both exist to make this switch instant.
The word gets used loosely for anything that undoes a release. A real rollback restores the previous state exactly. A fix pushed forward under the same name is not a rollback. That distinction matters once a database is involved. The database rarely has a previous state to restore to.
The asymmetry: code reverts, data and messages do not
Version 42 might also run a database migration: a new column, a renamed table, a backfill script. Rolling the code back to version 41 does not undo that migration. Old code now runs against a database shape it was never written for. This rollback breaks something the release itself did not.
Data written under the bad version has the same problem. Say version 42 saved orders with a wrong tax calculation for twenty minutes. Rolling back the code does not fix those orders. Someone has to find them and correct them by hand or by script, separate from the deploy.
Sent messages are the sharpest case. Say version 42 emailed every customer twice. There is no rollback for that. The messages are already in inboxes. This is why we treat rollback as a question asked before a release, not a button pressed after one. Can this change be undone? If not, what does it cost to be wrong for the time it takes to notice?
- Bad release detectedErrors spike or a check fails.
- Code revertsPrevious build redeployed in seconds.
- Schema staysA run migration is not undone by the revert.
- Bad writes stayData saved under the old version needs its own fix.
- Sent messages stayAn email or webhook already fired cannot be recalled.
The code box is the only one a rollback actually empties. Three others need a separate plan.
Common questions
01Can you always roll back a database migration?
Not the way you can roll back code. Adding a column is usually safe to leave in place, even if the code reverts. Dropping a column or renaming one is not. Previous code expects the old shape and finds it gone. A safer pattern splits a schema change into two steps: add, then remove later. That way a code rollback never lands on a database it cannot read.
02What is the difference between a rollback and a hotfix?
A rollback returns to a previous version that was already working. A hotfix is a smaller, new change that fixes the problem while staying on the current version. Rollback is usually faster under pressure, since it needs no new code. A hotfix is the right call when going backward would lose something you still need.
03Why do some teams say they can't roll back at all?
Usually because a migration removed something the old code needs. Or the release already sent something outward, an email, a payment, a webhook, that a code revert cannot recall. Once that happens, the only path is forward. Fix the current version, then correct any bad data or messages separately.
04Does feature flagging replace the need for rollback?
It reduces how often you need one. A feature behind a flag can be switched off with no deploy, which is faster than any rollback. It does not remove the need entirely. A flag only covers the feature it wraps, not every line that shipped alongside it.
Related terms
- Blue-green deployment →The release method built so a rollback is one switch instead of a redeploy.
- Feature flag →Turns a feature off without a deploy, narrowing how often a full rollback is needed.
- Software maintenance →Where we design the migration and rollback plan for a system already carrying live data.
