Website Handover Checklist: What to Give a Client at Launch

Create a handover the client can use

A website handover is the client-facing record of what was delivered, who owns the next decisions, and where to look before asking for help. It is most useful when it answers ordinary questions quickly: which service owns the domain, who updates event details, what is outside the agreed support period, and which open items still need a decision. A drive full of files can contain all of that information and still leave the client uncertain. The handover should select the pieces that matter to this website and explain why they matter.

Keep the editable working project separate from the package you give the client. Share references to accounts and access-request routes, never passwords, recovery codes, API keys, or private notes. The goal is a clear operating map, not a claim that the site has been audited or that every future issue is covered. For a local workflow that lets you select client sections and attachments before export, see Relayfolio.

The complete client handover checklist

1. Confirm ownership and access references

• Name the organisation that owns the domain, hosting, website account, analytics property, email service, and any third-party forms or payment services in scope.
• For each service, provide its public sign-in or support address and the named role that can request or approve access. Do not include credentials in the handover.
• State who is expected to renew each service and where renewal notices should be sent.
• List any supplier relationship the client must maintain, such as a host, registrar, email provider, or print partner.

2. Record what was delivered

• Give the website name, public URL, delivery date, and a short list of delivered pages or features.
• Link the location of source assets the client is entitled to keep, such as approved logos, photos, copy, or a content inventory.
• Describe the visible decisions that affect future edits: navigation labels, form recipients, language choices, image dimensions, or publishing workflow.
• Mark third-party material and licences that the client needs to track separately.

3. Make routine editing concrete

• Write short, version-neutral instructions for the tasks the client actually expects to do: edit text, replace an image, publish an event, request a change, and report a problem.
• For images, state the preferred format, aspect ratio or size where known, and where the approved source image is kept. Avoid implying that any uploaded image will work everywhere.
• Use one example content change to show the expected review path: draft, check the page, then publish.
• Keep admin paths specific to the actual site only when they are safe and current; otherwise point to the official service documentation or the person who manages access.

4. Set support boundaries and open issues

• State the support contact route, what information a useful request should include, and the date or scope of any included support.
• Separate defect reports from new work. A request for a new page, integration, design direction, or copywriting decision needs its own scope.
• List open items one by one with owner, next action, and a decision date where one exists.
• Do not mark a website as secure, backed up, compliant, or launch-ready unless an appropriate responsible party has separately verified that claim.

5. Close with acceptance

• Give the client a simple way to confirm receipt of the package and identify any missing handover item.
• Record what acceptance covers: receipt of the agreed deliverables, not a promise of future outcomes or platform behaviour.
• Keep the final checklist honest. Items remain unchecked until the relevant person completes them.

Package it for the next person

Before sending the handover, read it as someone who did not build the website. Can they identify what is theirs to maintain, find the correct support route, and see what remains open? Remove internal comments, working assumptions, credentials, and attachments that the client did not select. Then give the package a stable name and delivery date so it can be recognised later.

A practical package can be short: a handbook for context, a Markdown copy for easy editing, a checklist for completion status, and only the instruction images that support those notes. The free filled fictional handover example shows how these sections can read in a real package. If you prefer to start with a file, download the standalone Markdown checklist, adapt it to the actual site, and remove any section that does not apply.