The website handover checklist: what ownership actually means

Your company has launched a new website, but changing a product page still requires an email to the developer. The contract says you own the website, yet your marketing team cannot make routine updates, manage integrations, or explain how the system works without outside help.

That gap between contractual ownership and operational independence carries a cost. Every routine change becomes a request, every request enters someone else's schedule, and the knowledge needed to maintain your website remains outside your business.

At Vibery, we work from a straightforward belief: Clients should own what we build. Ownership needs to be visible in the access you control, the knowledge your team retains, and the work your people can complete without us.

This explainer sets out what a complete website handover should contain, when to plan it, and how to measure whether it worked.

Vendor dependence becomes a cost when routine work cannot move

External technical support is sometimes necessary. Security incidents, major integrations, infrastructure changes, and complex development often require specialist expertise. There is no business advantage in asking a marketing manager to perform work that properly belongs to an engineer.

The problem is dependence on external specialists for tasks your own team should reasonably control.

Consider an illustrative example: a B2B equipment supplier needs to update specifications across several product pages before a distributor campaign. The content is approved, but the website requires a developer to edit the page templates.

A simple business change now requires technical availability, additional coordination, and another round of review. If the campaign moves, the website may become the constraint rather than the channel supporting it.

This creates several forms of operational cost. There is the direct expense of technical requests, the time spent coordinating them, and the opportunity lost while approved changes wait. There is also continuity risk when the person who understands the system becomes unavailable.

Our view is that these costs should be assessed when selecting a website platform or delivery partner. A lower initial development effort can be offset by a website that is difficult to maintain.

As we explain in Speed without durability is decay, launch speed alone is an incomplete measure of value. The ability to maintain and improve what was launched matters after the initial delivery.

A complete handover covers access, source, knowledge, and people

A useful handover is a collection of verifiable assets and demonstrated capabilities. It should allow your company to operate the website, recover access, understand its dependencies, and appoint another qualified provider if necessary.

The exact deliverables depend on the technology and contractual scope. The following checklist provides a practical starting point for discussing that scope.

Access: control the accounts that keep the website operating

Domains and DNS. Your organization should control the domain registrar account and DNS settings. DNS, or Domain Name System, directs your domain to services such as website hosting and email. Record who can change these settings, where renewals are managed, and how account recovery works.

Hosting and administration. Identify who owns the hosting account, who can administer the website, and which permissions are assigned to external providers. Use named accounts where possible. Administrative access should be recoverable through company-controlled channels.

Analytics. Your company should control its analytics properties, measurement configuration, and relevant reporting accounts. Confirm that an employee can grant or revoke access without asking the original developer.

Source: retain what another team needs to maintain the system

Source code and build process. For custom development, identify the source repository, ownership or usage rights, dependencies, and instructions for producing a working deployment. A repository is the controlled location where software files and their change history are maintained.

Receiving files does not automatically establish unrestricted ownership. Third-party libraries, licensed components, and reusable software may carry separate rights. The agreement should identify what the client owns, what it is licensed to use, and what can be modified or transferred.

Content model. Document how content is organized: page types, product fields, categories, reusable components, relationships, and publication permissions. The marketing team needs to know which changes can be made through the content management system and which require development.

Integrations and keys. Inventory connections to CRM systems, forms, email platforms, analytics, payment services where applicable, and other external tools. Record the responsible account owner, purpose, permissions, and renewal requirements.

Credentials and API keys must be transferred or regenerated through secure channels and stored in an approved secrets manager. They should never be placed in ordinary documentation or shared spreadsheets.

Knowledge: document how the website works

Technical documentation. Include the architecture, hosting configuration, deployment method, backups, recovery procedures, scheduled maintenance, and known limitations. Instructions should describe the actual delivered system rather than a generic platform setup.

Editorial documentation. Provide guidance for creating pages, updating product information, managing translations where applicable, and checking how content appears before publication.

Measurement documentation. Explain what the team tracks, where the data comes from, and what each measure means. This prevents a change of provider from interrupting reporting continuity.

People: establish responsibility and demonstrate capability

Training sessions. Ask the delivery team to demonstrate routine operations, then have your own team repeat them. Useful exercises include publishing a page, updating a product, managing permissions, and checking a form submission.

Ownership and escalation. Name an internal business owner, the technical administrator, and the people responsible for content and measurement. Document who to contact for hosting failures, security issues, and specialist development.

A handover is stronger when each item has an owner, an acceptance check, and evidence that the recipient can use it.

Website ownership becomes meaningful when your team can make ordinary changes and recover from ordinary problems without the original developer.

Plan the handover in Value Map, rather than negotiating it at launch

Handover becomes difficult when nobody has agreed what independence means until the website is ready to go live.

In the V² Framework, we address this during Value Map, when the business outcome, baseline, scope, deliverables, KPIs, and First Value Date are established. The ownership requirements should be part of that initial scope.

For example, a B2B company commissioning a multi-market website might specify that its regional marketing teams must be able to update localized product information without engineering support. That requirement affects the content model, permissions, documentation, and training plan.

It should therefore influence the design from the beginning.

During Value Sprint, the agreed capabilities are built and tested. During Value Transfer, the team receives the agreed assets, access, documentation, and training, with acceptance based on practical tasks rather than files delivered.

Value Growth then examines whether the arrangement continues to work after launch.

The Vibery services approach includes ownership and handover within defined delivery scope. New requests are estimated and approved in writing before work begins, keeping additional development separate from the original commitment.

This matters because independence should be an agreed deliverable, not an open-ended promise that every future change will require no technical help.

Measure independence at 30, 90, and 180 days

A completed checklist demonstrates that the handover occurred. It does not prove that the client team is operating independently.

For that, we recommend tracking the share of routine website changes made in-house.

Define routine changes in advance. They might include editing approved copy, adding products, publishing articles, updating images, or maintaining market-specific information. Exclude major development, security remediation, and infrastructure work unless those activities are explicitly part of the internal team's responsibilities.

The calculation is:

In-house change share = Routine changes completed in-house ÷ Total routine changes completed × 100

An illustrative example shows how the measure could develop:

These figures are illustrative, not targets we promise or results from a client engagement. Actual targets should be agreed in Value Map against the team's baseline and operating needs.

At 30 days, review whether trained employees are using their access and documentation. At 90 days, examine recurring requests that still require outside help. At 180 days, assess whether the website can be maintained through staff changes and normal business operations.

Keep a simple change log identifying the task, date, person responsible, whether external help was required, and any delay. Also review the total volume of changes and their complexity.

A rising percentage can indicate improving independence, but it does not automatically prove better website performance. A team might complete more tasks internally while publishing slowly or introducing errors. Quality, turnaround time, and business outcomes still matter.

Within the V² Framework, these observations contribute to understanding Longevity. They are reported with their underlying measures, rather than treated as a standalone V² Score.

Audit your current website in one afternoon

You can assess your present ownership position without commissioning a full technical audit.

Start with the people who use the website: the Digital Lead, a marketing editor, and whoever manages infrastructure or external suppliers. Reserve one working session and collect whatever evidence is already available.

Work through five checks:

1. Verify access. Identify who controls the domain, DNS, hosting, website administration, and analytics. Confirm that company-controlled accounts can recover access.
2. Locate the source. Find the repository, licensing terms, deployment instructions, backups, and integration inventory. Mark anything missing or inaccessible.
3. Test a routine change. Have an internal employee update a low-risk page in a safe environment, follow the approval process, and confirm the result without developer assistance.
4. Check continuity. Ask whether another qualified provider could maintain the website using the available documentation and authorized access.
5. Record the gaps. Assign an owner, a corrective action, and a review date to each problem.

The output should be a short ownership register: what is controlled, what is documented, what the team can operate, and what still depends on a provider.

An afternoon audit will not establish full security compliance, verify every integration, or prove disaster recovery works. Those require separate technical checks. It can, however, reveal where operational control is unclear and where deeper assessment is justified.

Make the next handover measurable

Before approving another website project, define which routine changes your team should own, what assets must be transferred, and how acceptance will be tested. For an existing website, begin with the access and capability audit, then establish a baseline for in-house changes.

The objective is not to eliminate external specialists. It is to make continued external support a deliberate choice based on specialist value, rather than a condition imposed by missing access or knowledge.

If you need help defining that ownership baseline and the work required to improve it, book a Value Map call.