Website Handover Checklist for Clients: Files, Access and Everyday Tasks

A website handover should leave the client able to find the right account, perform routine tasks and understand who handles problems. Sending a login alone does not explain the domain, hosting, content, integrations or responsibilities that keep the website working.

Use this checklist to prepare the operational handoff. Adjust it to the agreed project scope and platform. Some projects include ongoing management, while others transfer day-to-day ownership to the client. The record should make that arrangement clear.

Start with a handoff inventory

List the systems and materials involved in the website. Typical categories include domain registration, hosting, the content system, source files, brand assets, forms, booking tools, analytics and any paid services. For each item, identify the owner and where it is managed.

Do not put passwords into the public handoff document. Use the provider's invitation or access-management process where available, or an appropriate secure transfer method. The inventory should tell the owner where to go and what the account controls without exposing credentials.

Confirm domain and hosting responsibility

Record which provider manages the domain and which provider hosts the application. These can be different companies. Identify the person responsible for renewals, billing notifications and DNS changes, and confirm that the client can reach the relevant account.

Include the production address and any staging address that remains in use. Explain which environment is appropriate for testing changes. A client should not have to infer whether a page is live from a filename or a message sent months earlier.

Document the content system

Show the client how to perform the tasks they are expected to handle, such as editing a paragraph, replacing a photograph or publishing a blog post. Use the actual interface and a realistic example. A short task-based demonstration is more useful than a tour of every setting.

Explain the limits of the role they have been given. The person editing copy may not need access to deployment credentials or infrastructure settings. Match access to the work rather than giving everyone the broadest available permission.

Deliver the agreed files and assets

Identify the source design files, approved exports, logo assets, content documents and other materials included in the handoff. Organize them so that a future team can distinguish approved work from abandoned concepts. Include any usage information the client needs for supplied assets.

An active review link is not the only archive. Swelik previews can expire or be replaced, so save the final artifact separately. Record which revision was approved and where the corresponding export lives.

Explain connected services

For each form, booking tool, payment provider or other integration, state what it does and who owns it. Record the destination of enquiries and the person responsible for monitoring them. Include a simple check the owner can perform if something appears wrong.

Avoid claiming an integration works because its button looks correct. Test the relevant journey in the appropriate environment and record the outcome. If a test depends on another provider or account owner, identify that dependency instead of marking the item complete prematurely.

Confirm the everyday operating tasks

Ask the client to perform a few routine actions while the project team is available. Can they find and edit the intended content? Can they identify the right inbox for a submission? Do they know how to request a change they should not make themselves?

This is not an exam. It is a way to discover missing instructions before the project closes. Update the documentation when the client encounters an unclear step so that the same question does not need to be answered repeatedly.

Record backups and recovery responsibilities

Describe the actual backup arrangement and who is responsible for it. Avoid generic statements such as “everything is backed up” unless the scope and recovery process are known. Identify which materials are covered and where the owner should seek help after a failure.

If recovery testing was included in the project, record what was tested. If it was not, say so. A handoff document should distinguish implemented procedures from recommendations for future work.

Include the review and decision record

Keep the final design decision, relevant revision history and any outstanding conditions with the handoff materials. This explains why the delivered page looks and behaves as it does. It also helps a future designer avoid reopening a resolved question without context.

The revision log template provides a compact way to preserve that history. Keep the operational handoff separate from the day-to-day comment thread so the client can find important information quickly.

Define the support path

Explain how the client should report a problem and what information to include. A useful report names the page, action, device and observed result. Identify the agreed contact point and any established support arrangement without inventing response promises.

Distinguish an issue with delivered behavior from a new feature or content request. The handoff does not need to settle every future scenario, but it should provide a clear place to begin the discussion.

Track outstanding items

Create a short list of anything still waiting on input, testing or confirmation. Give each item an owner and next step. Do not hide incomplete work in a document labeled final, and do not let a minor outstanding photograph obscure the status of the rest of the project.

Before closing the handoff, walk through the list together. Confirm which items are completed, which remain with the client and which are covered by a continuing arrangement. A clear exception is better than an implied promise.

A reusable handoff record

Use these fields: system or asset; purpose; account owner; access method; renewal or maintenance owner; everyday task; verification completed; outstanding item; support contact. Add links to instructions and files, keeping private access details in the appropriate secure location.

Start with the most important tasks rather than documenting every possible setting. The client needs a reliable route to operating the website, not a manual that is too large to use. For earlier project stages, the website checklist for clients connects preparation, review and handoff.

Frequently asked questions

Is handoff the same as launch?

They may happen together, but they are different activities. Launch makes the intended implementation available. Handoff transfers the knowledge, access and responsibilities agreed for operating it.

Should the review preview remain online forever?

Do not rely on that. Keep approved exports and decisions in the project archive. A temporary preview is useful during review, while the archive supports longer-term reference.

What is a good final handoff check?

Ask the client to locate the right account, complete a routine content task and explain where they would report a problem. Any uncertainty points to an instruction or ownership detail that should be clarified.