A website handoff is not simply an email containing a login. It is the verified transfer of ownership, access, knowledge and operational responsibility. For agencies, a structured handoff protects the client relationship, reduces launch risk and gives everyone a clear record of what was approved, transferred and still requires support.
Start the handoff before launch week
The best handoffs begin during planning. Name the person who can accept the website, decide which accounts the client or agency must own, and add handoff requirements to the website brief. Waiting until the final afternoon turns predictable administration into launch risk.
Agree one handoff owner on the agency side and one on the delivery side. They should maintain the checklist, confirm access and record acceptance. Other stakeholders can review the work, but responsibility for closing the handoff should not be distributed across a group chat.
1. Confirm approval and scope acceptance
Before transferring responsibility, compare the final website with the approved scope. Record which pages, templates, integrations and responsive states were delivered. If an item was removed, deferred or replaced, document that decision instead of relying on memory.
- Final sitemap and delivered URL list
- Approved desktop, tablet and mobile layouts
- Completed functionality and integrations
- Known limitations or deferred requests
- Written approval from the authorised stakeholder
A clear scope record also stops a handoff from becoming an unplanned revision round. If the delivery changed during production, update the scope document before asking the client to approve the launch.
2. Transfer domain, DNS, hosting and platform ownership
Business-critical accounts should be owned by the client or the agency responsible for the relationship. A freelancer or delivery partner may have delegated access, but should not remain the only person able to renew the domain, change DNS or deploy the website.
| Asset | What to verify | Preferred owner |
|---|---|---|
| Domain and DNS | Registrar, renewal, nameservers and recovery contact | Client or agency |
| Hosting or deployment | Billing, production project, environment variables and team access | Client or agency |
| CMS or commerce platform | Primary owner, billing and administrator roles | Client or agency |
| Third-party tools | Licence holder, renewal date and integration owner | Agreed per tool |
Verify access by asking the receiving owner to sign in. A username written in a checklist is not proof that the account, recovery email or multi-factor authentication works.
3. Organise CMS users and secure access
Give each person an individual account with the lowest role that supports their job. Remove temporary users, test accounts and unused administrator access. Never place passwords in email, Slack or a client-facing task; use a shared password manager and transfer multi-factor authentication deliberately.
- Confirm the primary administrator and recovery contact
- Remove shared or generic development accounts where possible
- Store recovery codes securely
- Record which supplier accounts remain active and why
- Schedule removal of temporary access after the support window
4. Verify content, media and licence records
The receiving team needs to know what it can edit and what it is allowed to reuse. Confirm that final copy, images, fonts, icons and downloadable files are in place. Record the source and licence for paid assets, plus any renewal or attribution requirement.
Provide original editable files only where the contract includes them. If the website uses a design system or reusable CMS components, explain their intended use so routine updates do not gradually break the interface.
5. Test forms, email routing, CRM and payments
A form that displays a success message can still fail behind the scenes. Submit every important form using a real test path, confirm the receiving inbox or CRM record, and check that notifications reach the right people. Test payment, booking and automation flows from the visitor action through to the final operational outcome.
- Contact and lead forms, including validation and spam controls
- Confirmation messages and internal notifications
- CRM fields, tags, pipeline stages and source attribution
- Booking confirmations and calendar ownership
- Checkout, tax, shipping, refunds and transactional emails where relevant
6. Transfer analytics, Search Console and tracking ownership
Analytics should sit in an account the client or agency controls. Confirm administrator access to analytics, Search Console, tag management, advertising pixels and consent tools. Record which conversions are configured and test the important events after the production domain is live.
Keep a note of measurement IDs, container IDs and verified domains, but do not confuse that inventory with ownership. The receiving party should be able to manage users, not merely view reports.
7. Complete final QA and record the launch state
Run final QA against the production website, not only the staging build. Check priority browsers and devices, navigation, redirects, metadata, indexability, performance, accessibility basics and error pages. Capture the approved launch state so later changes can be separated from launch defects.
- Production URLs return the expected status codes
- Canonical tags, sitemap and robots directives use the live domain
- Forms and conversion tracking work with consent choices
- Backups or version history are available and a rollback owner is named
- Critical redirects and 404 behaviour have been tested
- The approved launch date and release version are recorded
8. Provide documentation and focused training
Documentation should cover the tasks the receiving team will genuinely perform: editing pages, publishing articles, updating navigation, replacing media, managing products or reviewing enquiries. Short, task-based instructions are more useful than a long tour of every CMS screen.
Record the training session when permission is given and link it from the handoff document. Name the person responsible for keeping documentation current when the website changes.
9. Define post-launch support and responsibility
State when the support period begins, how long it lasts and what qualifies as a launch defect. New pages, changed requirements, third-party outages and content updates should not be left ambiguous. Include the response route, expected response time and the person authorised to approve additional work.
A complete handoff gives the receiving team control without leaving the delivery team responsible for undefined future work.
Final website handoff checklist
- Final scope and stakeholder approval recorded
- Domain, DNS, hosting and platform ownership confirmed
- CMS roles, secure credentials and recovery access transferred
- Source files, licences and third-party renewals documented
- Forms, CRM, booking and payment journeys tested end to end
- Analytics, Search Console and conversion tracking verified
- Production QA, backups and rollback responsibility completed
- Editing documentation and training delivered
- Support period, exclusions and escalation route agreed
- Temporary supplier access scheduled for removal
Use this checklist as part of the delivery process rather than a document assembled after the build. If your agency needs a white-label website partner to own production through QA, launch and handoff, agree those responsibilities before the project begins.
Turn the guidance into a dependable delivery system.
Oncreation works behind agencies on website structure, custom UI, development, QA and launch—with the agency remaining in control of its client relationship.
