Identify the changing boundaries
List the application code, configuration, database changes, and external behavior included in the release. Determine whether the previous version can understand data written by the new version.
When compatibility is uncertain, plan a staged change or a specific recovery procedure. Avoid assuming that restoring yesterday’s code will make a new data shape disappear. Include background workers and scheduled tasks in the analysis, not just the web application.
Define the decision point
Agree what evidence would cause the team to stop the rollout or revert. Choose checks that cover the affected workflow and designate someone to make the decision.
Make the previous release and its required configuration identifiable. Record the exact version rather than relying on a moving tag or an informal description such as “the one before lunch.” Know how the operator will access it if the normal deployment interface is unavailable.
Verify after returning
Check the application’s health and the user journey that motivated the rollback. Inspect work created during the failed release and decide whether it needs reconciliation, repair, or communication.
Record the result and preserve diagnostic evidence before cleanup removes it. A successful rollback restores useful operation while leaving the team able to understand why the release failed.
Rehearse important rollback paths in a suitable environment. If reversal cannot be made safe, acknowledge that explicitly and plan the release around a different recovery strategy. Clear limits are more useful than a rollback button whose consequences nobody has tested.
A practical example.
A release changes both application behavior and stored data. Returning to the previous application image may not be sufficient if that image cannot read the new representation. Review compatibility before defining “rollback” as a single deployment command.
Write the decision point, responsible person, and evidence that would justify returning to the previous version. Describe what happens to new records created after release and how the team verifies the restored behavior. Where a direct rollback is unsuitable, prepare a different recovery path and call it what it is. Rehearse with realistic state so the team does not discover the limitation while users are already affected. Keep the relevant artifacts and instructions accessible during the release.
Put it into practice.
- Check application, configuration, and data compatibility with the recovery target.
- Define who makes the decision and which symptoms trigger consideration.
- Verify the complete user workflow after recovery, including recently changed records.