Support & operations · Practical guide

Restore a known acceptable version, not merely the previous one

The team chooses the immediately previous deployment even though that version was never confirmed healthy.

Healthcare website support desk with a system checklist, telephone and orange notebook.
Know who to call and what help your support arrangement includes.

What to change

Select a known acceptable target based on evidence, not proximity in deployment history. Ask the release owner which version passed the required public checks and whether later operational dependencies remain compatible with it. Rehearse against that version before an emergency where possible. Record any trade-offs, such as losing a recent benign change, so the organisation can make an informed restoration decision rather than assuming every earlier version is safe to restore.

A worked example

Illustrative example

Illustrative test: A candidate version that predates a confirmed defect is compared with the immediate predecessor. The immediately previous release may already contain the defect now causing concern. The release owner identifies an earlier version with recorded public checks and reviews its compatibility with current services. A representative rehearsal confirms the chosen target and notes any benign recent change temporarily lost. The practice can then make an informed recovery decision, instead of treating the nearest earlier timestamp as automatic evidence of a healthy state.

Healthcare website maintenance with infrastructure, a status panel, tools and an operational checklist.
Monitor the useful journey, not just whether a server responds.
Healthcare backup and recovery illustrated by storage copies, an archive folder and a restoration route.
Test whether a backup can restore a usable service.

What this means for your practice

The immediately preceding release may contain an older unresolved defect or may never have been checked publicly. Ask the release owner to identify the last version with useful acceptance evidence and review its compatibility with current services. Where possible, rehearse that target before an emergency. Record any trade-off, such as temporarily losing a recent harmless improvement, so the practice can make an informed restoration decision. Older is not automatically healthier. The recovery plan should explain why the chosen version is suitable and which critical tasks were checked, rather than relying on its position in a list of deployments or a reassuring timestamp.

How to check the result

The chosen target has a justified health and compatibility record.

A mistake to avoid

Older does not automatically mean more reliable.

Turn reading into a next step

Your action checklist

Work through these checks with your team or supplier. Tick the ones you have resolved and leave unknowns open.

Checks to discuss

Record what you know, what is still missing and the answer you need from your team or supplier.

Use project decisions only, without personal, patient or confidential details. Entries stay in this page and are not submitted to Kay & Co. Copy or download before leaving; this page does not save your notes.

Further reading

These sources provide background for the topic. The practice examples and checklist are illustrative planning suggestions from Kay & Co.

Related guides

Need help with this?

Tell us what is getting in the way. Kay & Co. can help you understand the options and turn the next step into something that works for your practice.

Explore support & operations services or discuss your project.

Try the free Healthcare Digital Planner to find your starting priority.