A Website Handover Checklist for Agencies and Their Clients

Plan a website handover covering ownership, subscriptions, backups, inquiries, training and support so the client can operate what you deliver.

A website project can finish visually and remain unfinished operationally. The agency still holds the publishing account, the client cannot find the original images, and nobody knows who checks a failed inquiry. Choosing a website builder for client work therefore includes planning the handover. A clear delivery checklist makes the site easier to operate and gives both sides a specific way to decide whether the agreed work is complete.

Quick answer

Agree the ownership, maintenance and acceptance responsibilities before building. Hand over recoverable content, appropriate account access, verified inquiry delivery, a subscription register and a concise operating guide. Demonstrate common updates with the client and record unresolved items. Choose the builder whose working handover fits the client’s actual capability and support arrangement.

A working site needs an owner for its accounts, content and inquiry process.
Test recovery and common updates rather than handing over a list of passwords.
Define support boundaries and unresolved items explicitly.

Where the work gets stuck

The client receives a finished-looking site without control of an essential account.
Subscriptions renew without a clear owner or record of their purpose.
Every content change becomes a support request because no update process was demonstrated.

Agree responsibilities while the scope is still editable

List the assets the project will create or configure: pages, domain connections, hosting, source content, forms, integrations and analytics settings where applicable. Record who owns each asset and who is responsible for operating it after delivery. Distinguish the work included in the initial build from continuing maintenance.

Turn vague expectations into observable acceptance tasks. The client should know what a successful inquiry test looks like, which routine changes they are expected to make and which tasks require support. Keep unresolved commercial or legal questions with the appropriate responsible person rather than implying that a technical checklist settles them. A shared operating plan can reveal scope gaps before the launch deadline.

Hand over appropriate access and recoverable materials

Use the platform’s supported ownership and access arrangements. Verify the intended owner can reach the necessary controls and recovery route. Avoid leaving an essential asset tied only to an individual’s account without a documented transfer or continuity plan. Do not treat sending a shared password as a complete handover.

Provide approved text, original assets the client is entitled to use and relevant source or export files within the agreed scope. Explain what the export contains and what must be recreated elsewhere. If an asset remains with a provider or contractor, record the dependency and the supported recovery process. The practical question is whether the client can operate or move the site under the agreed arrangement.

Demonstrate the tasks the client will actually perform

Choose representative tasks such as editing service information, replacing an approved image, checking an inquiry and correcting a broken link. Let the client perform them in an appropriate environment while following the guide. Observing where the instructions fail is more useful than assuming a lengthy document proves the process is understood.

Include the page checks that accompany an update. W3C describes meaningful headings and page regions as aids to navigation; a routine content edit should preserve that structure. Check the edited page on a narrow screen, review links and verify any affected contact journey. Record the publishing steps and a simple way to recover from an accidental change.

Sources: 1

Create a subscription and integration register

For every continuing service, record its purpose, account owner, billing owner, renewal or review arrangement and the consequence of interruption. Use current provider information for charges and limits. A register should make dependencies visible without putting passwords, tokens or other secrets into an ordinary handover document.

Document how an integration is tested and who investigates a failure. For an inquiry connection, include the destination and expected message fields. For a reporting connection, identify its data source and refresh expectation. Explain which observations establish a working connection and which questions remain outside the delivery scope. An integration that nobody owns is an unresolved operating dependency.

Close the project with evidence and a support boundary

Keep an acceptance log listing the agreed task, test date, result and any unresolved item. Distinguish a correction still required for the agreed delivery from an optional enhancement. Do not hide an open issue behind a general completed label, and do not imply that a passing test eliminates every future failure.

Explain how support requests are raised, who can authorise changes and what maintenance has been agreed. Preserve a dated release package and the recovery instructions. The final review should leave the client able to identify the site owner, perform the expected routine work and find help when a defined exception occurs. That is a more useful handover than a presentation of finished screens alone.

From friction to a smoother workflow

The project has an appearance target but no operating owner.
Create an asset and responsibility register during scoping and agree the client tasks that will be demonstrated at delivery.
Measure: Assets with confirmed ownership and routine tasks with an acceptance test.
Training is delivered without checking understanding.
Ask the client to complete a representative update using the guide, then revise the unclear steps and retest the result.
Measure: Tasks completed independently and questions that require clearer instructions.
Support begins with an argument about what was delivered.
Save the acceptance results, unresolved items and agreed support route together with the dated release package.
Measure: Requests that can be classified using the documented scope and operating responsibilities.

Compare the options

Choose by fit, effort and tradeoffs.
Approach	Best fit	Tradeoff
Client-managed builder	A client able to operate the chosen editing and publishing workflow with suitable access.	Verify the actual update process, recovery route and support needs before handing it over.
Managed website service	A client who prefers an agreed provider to handle defined updates and maintenance.	Make responsibilities, access, recurring work and exit arrangements clear.
Tailored website or application	A project with a specific workflow that the verified standard tools do not adequately support.	Agree delivery, testing, documentation and ongoing technical ownership separately.

An illustrative example

Illustrative example: an agency prepares to hand over a small consultancy website. During the client rehearsal, the service text is easy to edit, but the guide does not explain how to verify the inquiry destination after publication. The team adds a controlled submission test, records the receiving owner and saves the expected message fields. It also documents which image originals are included in delivery. The client receives a demonstrated operating process rather than an unsupported promise of self-sufficiency.

Could a tailored solution fit?

Denisia can help scope the ownership register, delivery checklist and a narrow website or CRM handoff. If an existing builder meets the operating requirements, configuration and documentation may be the appropriate service. A custom dashboard or application should address a defined gap and include an agreed maintenance owner.

Discuss a web app, CRM workflow or dashboard

Your next steps

Agree the asset owners and routine client tasks during scoping.
Prepare recoverable materials and a clear dependency register.
Rehearse common updates and the inquiry journey with the client.
Close with acceptance evidence, open items and a documented support route.

Frequently asked questions

Is sending administrator credentials a complete handover?

No. Access is only part of delivery. The client also needs the agreed ownership arrangement, recovery information, materials, operating instructions and a tested process for the tasks they will perform.

Should the client own every technical account?

Choose the arrangement appropriate to the agreed service and the platform’s supported controls. Make ownership, delegated access and continuity explicit so essential assets do not depend on an undocumented personal account.

How do we distinguish a defect from a new request?

Use the agreed scope and acceptance tasks. Record unresolved delivery items separately from later enhancements, and give both sides a clear route for reviewing changes. A technical guide does not replace the applicable project agreement.

Sources

Page Structure Tutorial | Web Accessibility Initiative (WAI) | W3C

Continue reading

Explore the Website Planning and Delivery hub

Discuss your project

Get help with your next step.

Contact Denisia Webops