←  All terms
R
QA & Deployment

Rollback

A rollback returns a release or system change to a previously working state.

A rollback restores a release or system to a previously stable state when a change causes problems. Reliable rollback processes depend on clear versioning, dependable backups, and a tested recovery procedure. After reverting, critical functionality and user journeys should be checked to confirm that the system is operating correctly again. The concept is closely related to Deployment and Backup.

Read more

Deployment

Backup

CI/CD

Cutover

FAQ

Rollback

How can a rollback be prepared before a release?
It takes a named previous version, a rehearsed procedure, and clear criteria for when to roll back, for example failures in critical user journeys. The decision-maker is defined in advance. A rollback that was never practiced often fails under pressure on details such as missing permissions.
When does a rollback reach its limits?
Limits appear with data changes: if database schemas were migrated or user data was written in a new format, the old code no longer fits the data. External effects such as emails already sent cannot be undone either. That is why changes are planned to be backward compatible wherever possible.
How does a rollback differ from a backup?
A rollback returns to an earlier version, usually quickly and through version control. A backup secures data for recovery after loss or corruption. Rolling back code does not restore deleted data; that requires a backup. The two mechanisms complement each other.