A rollback is a prepared response to a release that causes unacceptable problems. Reinstalling the previous version may be enough for some changes, but other releases also alter data, configuration or external workflows. The recovery plan needs to recognise those differences. Small businesses benefit from a short release checklist that explains the decision to stop, who can make it and what happens to work entered after the change.
Identify what the release actually changes
Consider a Wollongong distributor updating its order approval rules. The release includes a new screen, a database field and an automated supplier notification. Returning the screen to its previous version may not undo notifications already sent or data written in a new format. Ask the team to list those effects separately. Decide which are reversible, which need a corrective action and which must be prevented from running until the release is verified. A small deployment can still have wide operational consequences if it initiates external actions.
Set a decision point with evidence
Agree the checks that matter immediately after deployment: staff can sign in, an order can be created, approval routes correctly and the right information appears downstream. Define what failure would trigger rollback rather than prolonged investigation in the live system. Choose a release time when both business and technical owners can observe these checks. The right window is not automatically late at night; a quiet period with no responsible people available can delay detection and make a simple issue harder to resolve.
Protect work created after the change
Restoring an earlier database can remove legitimate records created since that backup. Treat data recovery as a separate decision from deploying old application code. PostgreSQL's backup documentation describes different recovery approaches; the team's plan should explain which one applies and its limits. Prefer compatibility between adjacent application versions where practical, and test the recovery path in a safe environment. If manual reconciliation may be needed, identify the records and external actions to review. Do not describe a backup as a complete rollback strategy without that explanation.
Rehearse the decision and the return
Use a nonproduction release to practise a failed acceptance check and the resulting recovery steps. Record the observed outcome rather than assuming the steps will work in an incident. The release note should state:
- The application, data and integration changes included.
- The immediate checks and the person authorised to stop the release.
- The code rollback route and any separate data recovery decision.
- How records created during the affected period will be identified and reconciled.