A website handover checklist for business owners

Build an ownership inventory

List the domain registrar, hosting, content platform, email delivery, forms, and third-party subscriptions. Record the business owner of each account and the person responsible for renewals.

Use business-controlled accounts where practical. Do not depend on a freelancer’s personal subscription without understanding the consequences of separation. If a service cannot be transferred, discuss an alternative before it becomes essential to the live site.

Store access information securely. The handover document can identify the account and access process without exposing passwords, recovery codes, or private keys.

Receive the right technical artifacts

The required package depends on the platform. For custom code, you may need a repository, dependency lock file, build instructions, and deployment notes. For a site builder, you may need administrative ownership, editable templates, and supported export information.

For a database-driven WordPress site, files alone are not the whole site: the official backup guidance covers both files and the database. Agree the recovery method appropriate to your actual stack rather than assuming one ZIP archive works everywhere.

Request an asset inventory and relevant license references. Know which plugins, fonts, and integrations require ongoing payment.

Test one restore path

Ask for a documented recovery procedure and a safe demonstration in an isolated environment. The test should not overwrite the live site. Record what was restored, when it was tested, and what was excluded.

Define backup frequency based on how often important data changes. A static brochure site and a shop taking orders have different recovery needs. Agree retention, access, and who responds if a scheduled backup fails.

A file named “backup” is evidence of an archive, not evidence that the business can recover. The restore exercise exposes missing data, undocumented dependencies, and account limitations.

Learn the tasks you will actually perform

Ask for brief instructions on changing a heading, replacing an image, updating a service, and checking form submissions. Try these on a safe copy or through the agreed workflow.

Do not request a general tour of every feature when you need a few repeatable business tasks. Focus on the actions likely to happen after the freelancer leaves. Include how to preview and undo a change.

Test with a colleague who did not build the site. Their questions are useful evidence that instructions need clarification.

Close the launch checklist

Review redirects from important old URLs, the main enquiry or purchase journey, mobile presentation, and access permissions. Confirm who owns any analytics account and whether the required events work.

Basic accessibility checks, including keyboard use and readable contrast, belong in launch review. The W3C introductory checklist is a starting point; additional assessment may be necessary for your requirements.

Remove temporary development access when it is no longer needed. Make permission changes carefully so you do not disable an integration the site relies on.

Define maintenance and support

Record the support period, response expectations, and what counts as a defect under the agreed project. Separate new features, content updates, and third-party changes from fixes to the original scope.

An illustrative handover list could include account ownership, source/export, a tested restore note, editing instructions, subscription inventory, and one named maintenance owner. It is not a claim that every package includes these items. Put required handover work into the initial quote, while there is still time to price and schedule it.