List what the release changes
| Change | Rollback question | Evidence before release |
|---|---|---|
| Application version | Can the previous artefact run with current configuration? | Known artefact and rehearsal |
| Database field | Can old code read new records without loss? | Compatibility test |
| Outbound notification | Can duplicate sends be prevented after rollback? | Delivery identity and replay rules |
| New user records | How will writes after cutover be preserved? | Reconciliation and recovery owner |
Choose the stop signal, decision maker and previous version before opening the release window. Record a task-level verification such as creating and reading one synthetic booking. Technical health and successful user behaviour should both inform the decision.
Choose rollback or forward repair with evidence
A release deleted a column that the old version needs. Is switching back the executable sufficient?
Show the worked answer
No. The old version may fail against the changed schema. Use the rehearsed recovery or forward-fix plan, preserving new writes. A backup restore requires its own data-loss and reconciliation decision.
After recovery, check the affected task and a related unaffected task, then record the release and data state actually running. A successful rollback command is not proof that the customer journey is restored.