A website handover should let an authorised person operate the site, understand its dependencies and recover from a problem. Receiving a login or a folder called “final website” does not establish that those tasks are possible.
If you are changing agency, completing a build or arranging maintenance, use this checklist to record what exists and what has been tested. Keep contractual questions separate from technical evidence: possession of a file or payment of an invoice alone does not settle every ownership or licensing question.
1. Agree what the handover must enable
Start with the work the incoming maintainer will need to perform. Can they update content, publish a repair, receive form submissions and restore the required data? Which systems remain managed by another provider?
Record the agreed handover scope, known exclusions and responsible contacts. Ask for written clarity about custom work, third-party licences, data exports and continuing services. Where an agreement is unclear or disputed, obtain appropriate advice rather than treating a technical checklist as a legal decision.
2. Use an account-and-evidence matrix
This is a proposed working record, not evidence that any particular supplier has withheld access.
| Asset | What to identify | Evidence to request | Practical acceptance check |
|---|---|---|---|
| Domain and DNS | Registrar, authorised contact and renewal responsibility | Account access arrangement and current DNS record | Named business representative can locate settings and renewal details |
| Hosting and deployment | Live project, release process and support contact | Deployment instructions and last working release | Incoming maintainer publishes a harmless preview change |
| Source and assets | Repository, required files and licence information | Agreed access or export, build instructions and asset register | Preview can be built from the documented release |
| CMS and database | Content location, access roles and export process | Operating instructions and agreed backup procedure | A sample content update works in a safe environment |
| Forms and integrations | Destination, service owner and failure handling | Integration inventory and test instructions | One labelled enquiry is found at the intended destination |
| Measurement | Correct Analytics property and Search Console property | Named access and property identifiers | Business representative opens the intended reports |
| Recovery | Backup location, restore steps and responsibility | Dated recovery record and unresolved limitations | Restore is demonstrated in an agreed test environment |
Store passwords and recovery codes through an appropriate secure account-management process, not inside this matrix or an emailed spreadsheet. The matrix should identify the account and responsible person without exposing its secrets.
3. Separate domain, hosting and email decisions
A business can change its website maintainer without necessarily moving every service. Ask whether the proposed work changes the registrar, DNS, hosting, mailboxes or only the application. Mark each separately so nobody assumes that moving a website also transfers email.
ICANN’s guidance highlights the importance of the registrant and current contact details. Its transfer FAQ also distinguishes hosting changes from registrar transfers and describes possible transfer restrictions. Confirm the applicable process with the actual provider; do not promise that every domain can move immediately.
4. Check the connected services after any transfer
An account transfer is a starting point for review. Record who retains access, which integrations are connected and which service agreements continue.
For example, GitHub documents that repository transfers preserve associated webhooks, secrets and deploy keys. The incoming maintainer therefore needs an agreed access review, rather than assuming that transferring the repository removes all previous connections.
For measurement, confirm the existing property before creating anything new. GA4 permissions can apply at account or property level. A screenshot of a dashboard does not establish that the business can manage its access.
5. Rehearse a small operational change
Consider this hypothetical handover: a business receives source files and a CMS login, but the enquiry notification still depends on an undocumented service. The homepage looks correct; the handover is still incomplete because the incoming team cannot explain where enquiries go.
A useful acceptance sequence is to build a preview, make a reversible text change, publish it to that preview and locate the recovery instructions. Then submit one clearly labelled form test and confirm its destination. Avoid repeated production test messages when one recorded test answers the question.
Record the outcome and owner of any remaining dependency. A code rollback and a database restore are different tasks; demonstrate the recovery capability the business actually needs.
6. Define support after acceptance
Identify renewal responsibilities, the route for reporting incidents, supported tasks and the process for requesting additional work. Link the record to your maintenance proposal checklist, so the new arrangement covers both routine changes and failures.
For a technical handover discussion, review Nolixia’s website maintenance services. Send your website address and a list of the accounts and documents already available. Explain what is changing and what must keep working. This allows the handover work to be discussed before an unrelated redesign is assumed necessary.
