Define the release and acceptance checks
List the changes being deployed and the important journeys to verify afterwards. Name the person authorised to approve the release and the person who can stop it. Include configuration, DNS and data changes as well as application code. A release is easier to assess when its intended scope is explicit.
Identify what can actually be reversed
A previous application build may be easy to restore, while a database migration or external integration change may not be. Review compatibility between old code and new data. Keep backups where appropriate, but do not assume restoring an old database is acceptable if it would discard legitimate new transactions. Plan the recovery method for each type of change.
Set a decision point
Agree which failures require immediate recovery and which can be investigated while the release remains live. Use observable conditions, such as a broken checkout or a critical page returning errors. Avoid an open-ended period of repeated fixes with no clear owner. Keep communication channels ready so technical and business teams understand the current state.
Verify after recovery
Repeat the important checks after a rollback or other recovery action. Confirm that the system is consistent and that any affected enquiries or orders are accounted for. Record the actual cause when known and the next steps before attempting another release. The plan should be updated from the experience rather than treated as a one-time launch document.
Your practical checklist
- Define release scope and acceptance checks
- Assess reversibility of code, data and configuration
- Assign recovery authority and triggers
- Verify service and data after recovery
Working through a similar question?
We’re happy to help you find a practical starting point.
Talk to AMGK