Support & operations · Practical guide

Identify which project actually serves the live website

Several similarly named repositories and hosting projects exist, and the handover does not state which one serves the public domain.

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

Ask the outgoing supplier to connect the public website domain to its actual deployment project and maintained source. Use safe project identifiers and a verified release example so the incoming maintainer can follow the relationship. Mark obsolete copies explicitly instead of deleting them blindly during handover. The acceptance test should locate the live chain without private verbal guidance, reducing the risk that a future fix is applied to a dormant copy while visitors continue receiving the fault.

A worked example

Illustrative example

Illustrative test: The incoming maintainer traces a live revision back to its controlled source. Several projects may be named after the practice, including an old prototype and an unused hosting copy. The outgoing supplier maps the public domain to the active deployment and maintained source, then the incoming maintainer traces a known live change through that chain. Obsolete copies are labelled rather than blindly deleted. A future repair can now be directed at the project visitors actually receive, without relying on a familiar-looking folder name.

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

Several similarly named folders, repositories or hosting projects can exist after years of changes. Ask the outgoing supplier to connect the public domain to its active deployment project and maintained source. Use safe project identifiers and a verified release example. The incoming maintainer should be able to follow that chain without private verbal guidance. Label obsolete copies clearly rather than deleting them blindly during handover. This reduces the risk of a future repair being made to a dormant copy while visitors continue receiving the fault. Similar names or recent modification dates are clues, not reliable evidence of which project currently controls the public site.

How to check the result

The active publication chain is unambiguous and independently reproducible.

A mistake to avoid

Similar project names are not reliable evidence of which copy is live.

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.