Support & operations · Practice guide

Understand how a faulty release can be reversed

Illustrative situation

A release has a rollback command, but the team has not decided when to use it or whether new data remains compatible with the previous version. Returning to the previous software version may not undo changes already made to records or settings. Discuss recovery limits before launch so the team can choose a usable response rather than assume reversal is straightforward.

Read the guide Make your action list
Healthcare website support desk with a system checklist, telephone and orange notebook.
Know who to call and what help your support arrangement includes.

What this means for your practice

Agree when returning to the previous version should be considered and what that action cannot restore. Ask the responsible technical team to check how changed records and settings affect the available recovery options.

An example to discuss with your team

Rehearse a release that partially succeeds and changes data. Confirm the team does not assume code rollback alone restores a safe usable 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.

How to review the arrangement

Ask the supplier to rehearse a fictional release that partly succeeds and changes information. Which recovery options remain appropriate? Name the decision owner and agree the impact that prompts review. Keep limitations visible so the practice understands what the proposed rollback can and cannot restore.

Ask what returning to the old version would leave behind

Your supplier may call returning to an earlier version a rollback. Ask them to explain what that action restores and what it does not. An update can change settings or information as well as website files, and new work may have arrived since it began. Those differences can affect the recovery choice.

Use a fictional release that succeeds in one part and fails in another. The responsible technical team should explain the available options and what needs checking before normal work resumes. Agree who can make the decision and which business effects would prompt it. Keep the limitations in the release plan where the practice's contact can understand them. This avoids a pressured conversation in which everyone assumes 'go back' has the same meaning. A useful plan names a workable response for the actual service, with the appropriate people involved in judging the result.

How to check the result

Track releases with tested recovery options and documented limitations.

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.