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.
- Author
- Víctor Ribera
- Published
- Reading time
- 6 min read

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.
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
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
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
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
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
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
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
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
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
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


