Skip to content
Performance & SupportKanso editorial

What a professional website handover should include

A launch is not a handover. Clients need ownership, access, documentation and a clear operating model for the website after release.

Published
Reading time
6 min read
Kanso-style illustration of website knowledge and ownership being transferred

A website is not complete when it becomes publicly accessible. The organisation still needs to know what it owns, how to operate it, where critical accounts live and who is responsible when something changes.

A professional handover reduces dependence without pretending that every client should become a developer. It gives the right people enough access and understanding to make ordinary decisions safely and to involve technical support with clear context when needed.

01

Confirm ownership before launch

Domains, hosting, analytics, email services, repositories and third-party tools should be registered to appropriate business-controlled accounts. A supplier may administer them, but the client should not discover later that a critical account belongs personally to someone who has left.

Document billing contacts, renewal dates and recovery methods. Use shared organisational access where possible instead of circulating one password.

  • Domain registrar and DNS
  • Hosting and deployment platform
  • Source-code repository
  • CMS and media storage
  • Analytics, tag management and search tools
02

Create an access register

The handover should list systems, URLs, account owners and permission levels without putting raw passwords into a document. A password manager or secure invitation flow is more appropriate for credentials.

Remove temporary access and confirm that multi-factor authentication and recovery contacts work. Least-privilege permissions reduce the impact of mistakes while keeping ownership clear.

  • System and purpose
  • Business owner
  • Technical administrator
  • Access method and recovery contact
  • Date temporary accounts were removed
03

Document the architecture in practical language

Documentation should explain the parts a future developer or administrator needs to understand: framework, hosting, environments, content source, integrations, deployment and important conventions. It does not need to repeat information already clear from the code.

Include the reasons behind unusual choices. A short explanation of why a route, integration or cache rule exists is often more valuable than a long inventory of files.

  • Local setup and required versions
  • Build and deployment commands
  • Environment variables and where they are managed
  • External services and data flows
  • Known constraints and future considerations
04

Train editors on real tasks

Generic CMS tours are easy to forget. Training should use the organisation’s actual workflow: create a draft, replace an image, update metadata, preview a page, publish a translation and restore an earlier version.

Record the session or provide short task-based guides. Explain the boundaries as well as the features, including which changes can affect layout, accessibility or SEO.

  • Common publishing tasks
  • Image preparation and alt text
  • Heading and link practices
  • Preview, approval and rollback
  • When to request technical support
05

Hand over quality and compliance information

Provide the final test scope and any known exceptions. Include accessibility findings, browser coverage, performance baselines, redirect mappings and structured-data checks where relevant.

Privacy and cookie responsibilities should be explicit. The development team can implement tools, but the organisation must know which services collect data and who maintains consent and legal content.

  • Launch checklist and unresolved items
  • Accessibility statement or audit notes
  • Performance baseline
  • Analytics and consent configuration
  • Redirect and SEO migration records
06

Prove recovery, not only backup creation

A backup is useful only when it can be restored. Document what is backed up, how often, how long copies are retained and who can initiate recovery. For static sites, source code may be reproducible, but CMS data, media and configuration still require protection.

Run or document a restoration test before the project closes. Also explain rollback options for a failed deployment and the expected recovery time.

  • Content and database backups
  • Media and configuration
  • Source and deployment history
  • Restore procedure and responsible person
  • Incident contacts and escalation path
07

Define the post-launch period

The first weeks after release often reveal content questions, analytics differences and edge cases that did not appear in staging. A clear warranty period should distinguish defects from new requests and state how issues are reported and prioritised.

After that period, maintenance may continue through a care plan, a retainer or ad hoc work. The important point is that responsibility does not become ambiguous.

  • Warranty duration and scope
  • Support channel and response expectations
  • Maintenance owner
  • Update and security responsibilities
  • Process for new features
08

Use a final acceptance conversation

Do not end the project by sending a folder of links. Review ownership, documentation, open items and next actions together. Ask the client to perform the key tasks while support is still available.

A signed checklist can be useful, but the goal is shared understanding. The client should know what has been delivered, where it lives and how the website will be cared for.

  • All deliverables accessible
  • Accounts tested by client owners
  • Training completed
  • Known issues accepted and scheduled
  • Next review date agreed
09

Include a content and asset inventory

The client should know where original logos, fonts, photography, video and licensed assets are stored and what usage rights apply. Deliver editable source files when they are part of the agreement, not only compressed versions used by the website.

For content, identify imported material, generated text and items that require future review. This prevents the next campaign from starting with a search through personal drives and old messages.

  • Brand and design source files
  • Original and optimised media
  • Font and stock-asset licences
  • Content ownership and review dates
10

Schedule a post-handover health review

A short review after the team has operated the website is more useful than assuming training answered every question. Inspect publishing habits, analytics, form delivery, backups and any workarounds that appeared.

This review is also the right moment to refine documentation and decide whether continued care is needed. Handover is successful when the client can operate confidently and knows exactly when specialist help adds value.

  • Review four to eight weeks after launch
  • Check real editor questions
  • Confirm monitoring and recovery
  • Agree the next improvement priorities

Handover is part of the product

A well-built website can still become a liability if ownership and knowledge remain unclear. A professional handover turns the launch into an operating system the client can understand.

Plan access, documentation, training, recovery and support from the beginning of the project. The result is less dependence, faster future work and a healthier long-term relationship.

Explore ongoing website care

Continue reading

A clearer next step

Turn the article into a practical plan.

Discuss the current situation, priorities and the smallest useful next step for your website.

Back to all articles