Website Handover: What Must Actually Be Delivered After Launch

A website has not been properly handed over simply because it is live.

Many projects end with a URL, an admin login, and “contact us if anything comes up.” That feels convenient until a domain needs renewal, a plugin subscription expires, nobody controls Search Console, or a critical service still belongs to a freelancer’s personal account.

A good handover is not optional paperwork. It determines whether the client truly owns, maintains, and can recover the website.

What the client should own after launch

Access and ownership

Domains, DNS, hosting, repositories, CMS accounts, analytics, Search Console, tag management, email services, and payment providers should sit under traceable company-controlled accounts. Personal accounts belonging to individual suppliers create unnecessary dependency.

GitHub repository roles should be assigned deliberately. Google Search Console separates owners and users with different permissions. The goal is not to give everyone full access, but to keep the organization operational.

Technical documentation

At minimum, document:

• architecture and services
• deployment and rollback
• environments and domains
• backup and restore
• secrets and rotation
• integrations and webhooks
• recurring maintenance tasks
• known limitations and technical debt

Contracts, licences, and recurring cost

Who pays for hosting, plugins, fonts, stock assets, monitoring, email delivery, or CDN services? When do subscriptions renew? Which licences can be transferred? A launch without a cost inventory creates surprises instead of a plan.

Functional and acceptance status

The handover should record which features were tested, which browsers and devices were covered, and which items remain intentionally open. Otherwise, every later disagreement becomes a contest of memory.

Handover red flags

• The agency owns the only administrator account.
• The domain sits in a private account.
• Nobody except one developer can deploy.
• There is no current backup or restore evidence.
• Licences cannot be transferred or are about to expire.
• Consent, tracking, and form configurations are undocumented.
• There is no list of external data recipients.
• Monitoring and error alerts still go to former suppliers.

A useful handover session

A handover should do more than send files. Walk through deployment, user management, content editing, backup, recovery, and incident contacts together.

Test at least one critical process live. Let the client perform a deployment or content change where that matches the operating model. Documentation nobody can follow is decorative security.

What Website-Pflichtencheck would review

An independent handover review checks ownership, access, permissions, documentation, recurring costs, technical dependencies, privacy-relevant services, recovery capability, and the actual operating state.

This is particularly valuable before the final invoice, after an agency change, or when a website is moving in-house.

A professional handover ends dependency, not responsibility. If the website only works while one particular person remains available, the project is not technically finished.