What a Website Support Handover Should Include Before Go-Live

A website can be ready to launch and still be unprepared for live operation. The pages have been approved, the main journeys work, and the final defects have been closed. But once the project team steps back, basic questions can suddenly become difficult to answer. Who controls the domain? Which supplier receives an alert? How is a failed release rolled back? Does anyone know whether an important form has stopped delivering email?

These are not minor administrative details. They determine whether the website can be supported safely after launch. A platform that depends on undocumented accounts, informal knowledge, and one developer's memory may look complete while carrying a large amount of operational risk.

A good support handover closes that gap. It gives the people running the service a clear view of the technology, the ownership model, the routine maintenance work, and the response expected when something goes wrong. It should be treated as part of delivery, not as a document assembled during the final afternoon of the project.

Support planning needs to start before the launch date

Handover is often scheduled as the last project task, after build and acceptance testing. That leaves very little time to discover that access is missing, monitoring has not been configured, or a critical third-party service belongs to a former employee's account.

The stronger approach is to design the operating model while the website is being built. Support requirements should influence hosting, integrations, account structures, logging, deployment, and content permissions. The team taking responsibility for the live service should also be involved early enough to test the process, not simply receive it.

This changes the acceptance question. Instead of asking only whether the website works today, the project asks whether another authorised person could diagnose, change, recover, and explain it tomorrow.

Name the service owner and the technical owner

Every live website needs clear ownership at two levels. The service owner makes decisions about priorities, content, user needs, risk, and acceptable disruption. The technical owner is responsible for the platform's condition, including hosting, updates, monitoring, security, backups, and technical suppliers.

Those roles may sit with the same organisation or be shared with a support partner, but the boundary must be explicit. Otherwise routine decisions become slow and incidents become confused. The hosting provider assumes the web agency is investigating. The agency expects an internal IT team to check DNS. The content team reports a problem but does not know who can authorise an urgent change.

The handover should record named owners, deputies, contact routes, support hours, escalation paths, and the decisions each party is allowed to make. It should also identify commercial owners for licences and suppliers, because technical recovery can be delayed if nobody has authority to renew or change a service.

Build a complete dependency inventory

A modern website is rarely one self-contained system. Even a relatively straightforward content-managed site may rely on several organisations, platforms, credentials, and renewal dates. If those dependencies are not recorded, the support team is working with an incomplete map.

The inventory should cover at least:

• the domain registrar, DNS provider, hosting environment, content delivery network, and web application firewall;
• the CMS, custom code, themes, plugins, package dependencies, and paid licences;
• source control, build pipelines, deployment targets, and test environments;
• transactional email, form delivery, spam protection, consent tools, and analytics;
• search, maps, payments, authentication, CRM, data feeds, and other external APIs;
• backup locations, retention periods, restoration responsibilities, and encryption keys;
• certificate, domain, licence, and supplier renewal dates.

Each entry needs more than a product name. It should state what the dependency does, who owns the account, where access is held, how failure becomes visible, and what part of the website is affected. That makes the inventory useful during an incident rather than merely complete on paper.

Transfer access without transferring bad account practices

Handover should not mean emailing a collection of shared passwords. Personal accounts, reused credentials, and missing multi-factor authentication create avoidable risk and make it difficult to understand who changed what.

Wherever possible, the live service should use organisation-owned accounts with individual user access, appropriate roles, and multi-factor authentication. Recovery methods should remain under organisational control rather than pointing to a supplier's personal phone number or an employee who may later leave.

The support team also needs an agreed process for adding and removing access. That includes developers, content editors, analytics users, hosting administrators, and third-party suppliers. A secure emergency route can be useful, but it should be controlled, audited, and tested rather than improvised during an outage.

A simple access check before go-live is valuable: ask the incoming support team to perform the tasks it will actually need to complete. Can it reach the hosting console, repository, test environment, CMS, analytics, DNS, and backup system? Can it do so without borrowing a project team member's account?

Document deployment, maintenance, and rollback together

Instructions for making a change are incomplete if they do not explain how to recover from one. The handover needs a repeatable path from development through testing to production, with clear approval points and a rollback method that matches the technology in use.

For a content-managed website, that should include the process for core, theme, and plugin updates as well as custom code. Applying every update directly to production may be quick, but it gives the support team little room to detect compatibility problems before users do. A test environment and a small set of meaningful checks provide much stronger control.

Backups also need to be described in operational terms. It is not enough to say that they run daily. The team should know what is backed up, where copies are stored, how long they are retained, who can restore them, and when restoration was last tested. A backup that has never been restored is evidence of a scheduled job, not yet evidence of recoverability.

Monitor the service users depend on, not just the server

An uptime check can confirm that a page returns a response while important parts of the service are failing. A form may accept submissions but stop sending them. A payment callback may fail. Search results may be empty. An integration may be building a growing queue of unprocessed records.

Monitoring should therefore reflect the site's most important journeys and dependencies. Depending on the service, that may include:

• homepage and key landing-page availability;
• certificate expiry, DNS changes, server capacity, and error rates;
• form submission and transactional email delivery;
• login, search, checkout, booking, or account journeys;
• scheduled jobs, queues, data feeds, and API failures;
• backup completion, malware scanning, and security events;
• analytics or consent failures that remove visibility without taking the site offline.

Every alert needs an owner and a response. If notifications go to an unmonitored mailbox or generate so much noise that they are routinely ignored, the monitoring is not providing meaningful protection. The handover should show what each alert means, its severity, who receives it, and what first diagnostic step to take.

Give content teams a safe operating model

Many post-launch problems come from ordinary content work rather than software releases. A page is removed without a redirect. A large image affects performance. Navigation changes hide an important service. An editor adds a heading structure or link label that makes the page harder to use with assistive technology.

The handover should give content teams enough guidance to work confidently without turning every change into a development ticket. That means appropriate CMS roles, a clear publishing workflow, and practical standards for images, links, headings, alternative text, documents, redirects, and page removal.

It should also identify who owns the content after launch. A technically healthy platform can still become less useful if outdated pages accumulate, documents have no review date, and nobody is responsible for the structure users rely on. Content governance belongs in the support model because the website's condition is both technical and editorial.

Agree the incident process before the first incident

When a website problem is already affecting users, teams should not be deciding for the first time what counts as urgent. The handover needs simple severity definitions based on impact. A complete outage, suspected breach, failed payment journey, or inaccessible critical service requires a different response from a minor layout defect.

For each severity, record the contact route, expected acknowledgement, investigation owner, communication responsibility, and escalation point. Include relevant supplier references and out-of-hours arrangements where the service genuinely requires them.

The process should also explain how evidence is preserved. Logs, timestamps, screenshots, deployment references, and affected user journeys help the technical team diagnose the issue and allow the organisation to produce a credible account afterwards. That is much harder when incident communication is scattered across personal messages and undocumented calls.

Capture a baseline and test the handover

Before launch, record the condition of the website in ways that can be compared later. The baseline might include performance results for key templates, accessibility checks, security findings, indexation settings, error rates, backup status, and the versions of important platform components.

This does not need to become an enormous report. Its purpose is to distinguish a new problem from an existing one and to show what the project accepted at launch. It also gives the support team a starting point for improvement rather than forcing it to reconstruct the site's history after something changes.

The handover itself should then be tested with a short operational exercise. Ask the incoming team to find an error log, deploy a low-risk change, roll it back, locate a supplier contact, restore a copy of the site in a safe environment, and explain the response to a simulated alert. Gaps found during that exercise are much cheaper to close before the original project team disperses.

Keep the handover live during the first month

Documentation starts ageing as soon as the website launches. The first few weeks reveal which alerts are noisy, which instructions assume too much knowledge, and which minor operational tasks were overlooked during delivery.

A scheduled review after the first month gives the project and support teams a useful point to close those gaps. Update the dependency inventory, confirm that renewals and accounts sit with the right owners, review incidents and support requests, and add missing steps to the runbook. The result should be a living operating record, not a static handover pack stored in an old project folder.

Conclusion

A successful go-live proves that the website can be released. A successful handover proves that it can be run. The difference is clear ownership, controlled access, documented dependencies, tested recovery, useful monitoring, and a support process built around real user impact.

When those elements are included in delivery, the website is less dependent on individual memory and better prepared for routine change or unexpected failure. That is what turns a completed build into a service the organisation can operate with confidence.