Rollback
A rollback restores a website or application to a previous known state after a change creates a problem.
It is a recovery technique used when repairing the new version immediately would be riskier or slower than returning to the previous one.
What Can Be Rolled Back
Depending on the system, a rollback might restore:
- Previous code release
- Previous container or build
- Previous configuration
- Previous Theme
- Previous database state
- Previous deployment
Not every change is equally easy to reverse.
Rollback vs. Restore
A rollback generally reverses a recent technical change.
Backup & Restore is broader recovery from stored copies.
For example:
Rollback
Version 2 caused an error. Return to Version 1.
Restore
The production database was corrupted. Recover yesterday's backup.
Sometimes both are required.
Why Database Changes Are Different
Code can often be redeployed quickly.
Database changes may modify:
- Schemas
- Content
- Orders
- Users
- Transactions
Returning to an earlier database backup could also erase legitimate activity created since that backup.
That makes rollback planning especially important for transactional sites.
Why It Matters
Every significant Deployment should answer:
What happens if this does not work?
Without that answer, teams can become trapped debugging live production while visitors continue encountering the problem.
Common Problems
Common problems include:
- Previous build no longer available
- Production modified manually after deployment
- Database changes incompatible with old code
- No record of previous configuration
- Rollback procedure never tested
- Restoring an old database deletes legitimate new information
How to Improve
Plan reversibility before high-risk deployments.
Know:
- Previous working release
- How code is restored
- Whether database changes are reversible
- Whether Backup & Restore is needed
- How the site will be verified afterward