Website handover and maintenance: a practical checklist

What should a website handover include?

A website handover should include domain and hosting ownership, administrator access, source code where agreed, content and data exports, backup and recovery instructions, and a maintenance plan. Test that the receiving team can publish an update and restore a backup. A login by itself is not a complete handover.

Confirm account ownership

Identify the owners of the domain, hosting, email, source repository and any paid service. Make sure the business has an appropriate recovery method and that access does not depend on a former employee’s personal account. Store credentials through the business’s approved process.

List who can administer each service and remove obsolete access when responsibility changes. Payment providers, analytics and app-store accounts may require separate checks even when they are connected to the same website.

Document how the site is published

The handover should explain the application, deployment process and configuration responsibilities. A new authorised maintainer needs to know how changes reach the live site and which files or data must persist between releases. Identify any background jobs or external services the site depends on.

Keep environment-specific secrets out of ordinary documentation and source history. The goal is a usable operating guide with a secure access process, not a shared document containing every password.

Rehearse the CMS tasks

Have the intended editor create, preview, publish and update a representative page. Test media upload, navigation editing and the handling of an old URL. Confirm which fields affect search titles and descriptions and which are only internal planning notes.

Use the permissions of an ordinary editor where that role exists. A demonstration performed only with an unrestricted administrator account may hide limitations or access problems that staff will encounter later.

Check backups by considering restoration

Agree which files and databases are copied, where the copies are stored and who can restore them. Set frequency and retention according to the consequences of losing recent changes. A backup process should have a documented verification step.

Consider dependencies such as uploaded media and provider configuration. Recovering a database alone may not restore the complete service. Assign responsibility for coordinating restoration if more than one supplier is involved.

Verify the important visitor journeys

Check the public pages, enquiries, downloads and any payment or account flow using the production configuration. Confirm where form messages arrive and who follows them up. An attractive site with an enquiry form that nobody receives is not a complete handover.

Review redirects, sitemap coverage and the intended indexing settings for the live environment. Local or staging sites may correctly remain blocked from search, so the launch process needs to distinguish those environments rather than copy their settings blindly.

Put maintenance terms in writing

State support hours, request channels, escalation contacts and what is included. Distinguish routine updates and defect handling from new features or major redesign work. Hosting incidents, provider outages and email delivery may involve other parties.

Keep a record of renewal dates, licence responsibilities and the next review. Curobotic can assess a site before agreeing a maintenance scope, so support begins from a clear understanding of the system rather than an undocumented assumption.