Website handover: access, source files and backups

What to receive before a website project ends. Check domain control, hosting, source files, backups, analytics and support with a practical handover checklist.

Download the handover checklist Verify the handover

Handover is complete when you can operate the site

Receive more than a live URL and an admin password. You need verified access, agreed content and source deliverables, a usable backup, a subscription register and a support process. Someone on your side should be able to sign in independently and understand how to recover the service.

Use this checklist before closing a development project or changing suppliers. It covers technical handover. Record rights, licences and deliverables in your agreement: possession of files alone does not establish the extent of your rights.

Control: A responsible person in your business can access the domain, hosting, CMS and recovery options.
Reproducibility: Deliverables support the agreed deployment or migration method, with platform limits recorded.
Continuity: Enquiries, renewals, backups and support have named owners.

Check each layer of access

Domain: Registrar account, recovery contact, renewal date and responsible person. Check who is recorded as the registrant and the agreed transfer process.
Hosting: The project is in the intended account, with file and database access and clear billing details. CMS access does not replace hosting access.
Website administration: A named account with the required role, editing instructions and a recovery process.
Analytics and search: Access to the existing counters and verified search properties in your account. Do not replace them with new properties without a specific reason.
Connected services: Email, CRM, payments, forms, notifications and other services: account, role, responsible person and recovery method.

For example, Google Search Console distinguishes owner and user roles. Receive the appropriate role and verify it from your own account, rather than relying on a supplier screenshot. Official Search Console access documentation

Transfer secrets through a secure channel. A shared checklist should record the service, role and verification result, without passwords, tokens or customer personal data.

What to receive alongside access

Current copy, images and agreed design deliverables. List restrictions imposed by third-party licences.
For custom code: the agreed repository or release archive, dependencies, build and deployment commands, and configuration instructions without exposed secrets.
For a site builder: the transferred project, editing permissions, subscriptions and explicit export limitations. Do not assume migration as ordinary source code when the platform does not support it.
A backup with an agreed scope, creation date, storage location, responsible person and recovery instructions.
A list of integrations and technical accounts, including what stops working if each account is disabled.

A backup needs verification, not just a download

Backup scope depends on the system. Official WordPress documentation treats the database and files separately: a typical full recovery needs both. Static websites and hosted builders have different requirements, which should be stated explicitly. WordPress backup documentation

Verify recovery on an isolated copy with outbound notifications and payments disabled. Agree how personal data will be handled first. Restoring over the live site as a test can overwrite new enquiries.

Five checks before accepting handover

Your responsible person signs in from their own device. Recovery contacts and permissions are verified.
The agreed release opens, core pages and editing work, and the domain and certificate match the live site.
Enquiry intake is checked through an agreed procedure without accidental emails to real customers. Any test record is clearly labelled and counted separately.
A technical person reproduces deployment or recovery on a separate copy using the supplied instructions. Limitations are recorded explicitly.
The received items and open issues are recorded: what is missing, who fixes it and when it will be checked again. Record launch and support end dates separately.

Example: editing works, but recovery is missing

Consider a hypothetical handover: a manager can edit copy, but hosting is billed through the developer account and the backup contains only files. This is a partial handover. Hosting control, renewals, complete backup scope and a recovery check remain open. Successful text editing does not close those items.

Download the shared verification checklist

Agree what happens after handover

Separate defects in the agreed release, content changes and new functions. State the support channel, who receives issues, what diagnostic information to provide and which services are billed separately. Support duration should be explicit for your project rather than implied by the word launch.

BYstudio offers a free initial review. For a new site or an existing handover, we first establish the platform, available access and limitations, then agree the verification scope. Missing source materials can limit what can be recovered.

Website handover questions

Is an administrator login enough?

No. Editing access does not necessarily give you control of the domain, hosting, subscriptions or recovery. Check each layer separately.

Do we need source files for a site-builder project?

Check the platform capabilities and project terms. Export may be limited. In that case, confirm transfer to your account, copies of content, connected services and a clear list of what cannot be moved.

Should we remove the developer immediately?

First verify your own access, recovery, integrations and support arrangements. Then agree the roles that remain necessary. Do not disable technical accounts blindly: publishing or enquiry delivery may depend on them.

Does a downloaded archive count as a backup?

Only after its contents and recovery have been checked. An archive may omit the database, uploads or settings. Receive recovery instructions and verify a restore safely.

Who pays for the domain and services after launch?

Agree account ownership, billing responsibility, renewal dates and who receives alerts. A website working today does not establish that renewals are covered.