Skip to main content

Why a Small Release Still Needs a Recovery Plan

Software Engineering, Testing, Cloud & DevOpsBlog Posts

By Jefferson Otonbara Imgbi

Published
8 October 2026
Last reviewed
8 October 2026
Prepare a proportionate recovery decision before a small software change reaches users.
Image
A deployment workstation with a backup drive and recovery notes.

Small describes the change, not every consequence

Changing one field or one line of configuration can affect a larger user journey. The size of the edit does not tell you whether users can still sign in, submit a form or find their records. My recommendation is to prepare a proportionate recovery plan alongside the change. That means knowing what to check and what to do if an essential behaviour fails.

Connect the change to the journey

Imagine a fictional team changing a registration form label and validation rule. The label looks correct, but the new validation rejects a legitimate entry. A review limited to the visible wording would miss the problem. Test the affected journey with representative permitted and invalid inputs, and check the response the user receives. Keep the agreed requirements close to the test evidence.

Define the recovery decision

Record who may stop the release, which failure would trigger recovery and how the previous working state can be restored. A backup is useful only when the team understands what it contains and how restoration affects newer data. Where a change modifies data or compatibility, simply replacing an old file may be insufficient. Use the environment’s established deployment arrangements and test the recovery approach appropriately.

Check after deployment

GOV.UK deployment guidance recommends testing changes before production and checking essential behaviour after deployment. It describes smoke tests and planning the response when they fail. In a small project, the equivalent might be a brief documented check of the critical journey followed by a clear decision to continue or recover. It should examine actual behaviour rather than rely only on a successful deployment message.

Practise without risking a live service

Use a training environment to write a change note, run the expected-behaviour checks and rehearse the recovery decision. Record the version, dependencies and evidence. A short plan that another person can follow is more useful than an elaborate document nobody has tested. Keep the preparation proportionate, but do not confuse a small edit with an absence of risk.

Source and editorial note

Author: Jefferson Otonbara Imgbi. Reviewed 8 October 2026. The recommendations and fictional examples are original RDE editorial learning material. The source below provides background, not endorsement of RDE.

GOV.UK Service Manual: deploying software regularly

Cover image: AI-generated illustrative scene created specifically for this resource.

Related resources

Explore related RDE learning