Website handover guide
What a complete website handover should include
A launch is not a handover. The project is complete when the business can find its accounts, operate routine tasks and understand what continues after the supplier steps back.
The useful numbers, with the conditions attached.
- Transfer business-controlled access before the project is treated as complete.
- Document routine editing, renewals, support and third-party services.
- Test the business’s ability to receive enquiries and recover key accounts.
Transfer access in a controlled way
List the accounts that make the site operate: domain registrar, hosting or platform, content system, analytics, form destination, email sender, consent tools, payment providers and any integrations. Confirm the business has its own recoverable owner-level route where appropriate, not merely a supplier’s shared password.
Use individual access and secure credential handling. A handover should state who holds each role and how a new owner is added, rather than placing credentials in a downloadable document. Remove temporary development accounts when they are no longer needed.
- Domain and DNS
- Hosting or platform
- Content editing
- Analytics and measurement
- Forms, email and integrations
Document the operational essentials
Documentation need not be an encyclopaedia. It should answer the questions the business will actually face: where the site is hosted, which services renew, how to make a basic content change, how to report a fault and what is outside routine editing.
Include the current site map, technology or platform summary, key integrations and support contacts. Record dates and account ownership, then keep the document where the business can update it when staff or suppliers change.
- Account and renewal register
- Editing guide
- Support and escalation contacts
- Integration summary
- Known limitations or planned work
Train for the tasks the business will perform
Training is most useful when it uses the live tasks: edit a service detail, change an opening time, review a form submission or publish an approved article. A long dashboard tour without practice is easily forgotten and can leave staff worried about changing anything.
Decide which edits are safe for editors and which should be requested from technical support. Clear boundaries protect the site while allowing the team to keep factual content current. Record the steps in a concise format that a new staff member can follow.
- Routine content edit
- Media upload guidance
- Form submission check
- When to request technical support
Verify the handover with real checks
Ask the business owner to sign in to key accounts, receive a test enquiry and locate the renewal information. This is more reliable than assuming that an emailed link will be available when it is needed. Resolve access issues while the project team is still engaged.
Close with a small list of open items, ownership and dates rather than leaving informal promises. It distinguishes completed handover from future maintenance or growth work and gives both sides a clear record of the project’s final state.
- Owner account login
- Test enquiry received
- Renewal record located
- Open items agreed
- Supplier access reviewed
Common questions
Questions worth settling before you commit.
Should I receive the domain login?
The business should have a recoverable account and a clear route to control domain settings. A supplier can retain delegated access for support.
Do I need the website source files?
It depends on the platform and agreement, but you should understand what is provided, where the live site is managed and how future suppliers can work with it.
What if I do not plan to edit the site?
You still need ownership, renewal and support information. The ability to act matters when the supplier relationship changes.