Website Handover: What Your Developer Should Deliver Before Final Payment

A finished website is not fully delivered because it looks correct in a browser. The owner must control the domain, infrastructure, accounts, code, licenses, data, documentation, and recovery paths. This guide turns handover into evidence you can verify before approving the project and releasing final payment.

A useful website handover gives the receiving team control, documentation, and proof that routine operations work. Photo: Rawpixel Ltd via Wikimedia Commons, CC BY 2.0; cropped.

What is a website handover checklist?

A website handover checklist is an acceptance register for everything the owner must receive, control, understand, and test when development ends. It covers accounts, code, assets, licenses, data, security, operations, documentation, training, and support so the website can run without hidden dependence on the original developer.

The practical test is independence. A named employee or successor vendor should be able to sign in, publish a safe edit, receive a form submission, read performance data, create a backup, follow a rollback procedure, and identify support responsibilities without borrowing the original developer’s personal account.

If the build is still being defined, settle scope first with LeWebsite’s website requirements document template. Handover criteria belong in that agreement before work starts, even though the final verification happens at delivery.

What should a complete website handover include?

A complete handover should include owner-controlled accounts, production and staging access, source files, repository history, licenses, integration inventory, data exports, security records, tested backups, deployment and rollback instructions, analytics permissions, content guidance, training, and support terms. Each item needs an owner, location, status, and acceptance test.

Do not accept “credentials sent” as a completed row. Confirm the account belongs to the business, recovery methods reach the business, billing is visible, permissions are sufficient, and the account can survive the vendor relationship. Delivery is a file transfer; handover is verified operational control.

Who should own the domain, DNS, and certificates?

The business should control the domain registrant account, renewal method, recovery email, multifactor authentication, DNS service, CDN, and certificate process. A developer may receive delegated access, but the company should remain the account owner and know where every authoritative setting lives, when it renews, and who can change it.

Verify the registrar account

Confirm the legal business or authorized representative appears in the account profile, the recovery address is monitored, and renewal does not depend on a former employee or agency card. Review the current ICANN registrant rights information, while treating contract or ownership disputes as matters for qualified counsel.

Map DNS, CDN, and certificate responsibility

Record the authoritative nameservers, DNS host, CDN or proxy, mail records, certificate automation, and renewal alerts. Export the current zone before changes. The handover should identify which records serve the website, email, verification tools, and third-party platforms so a future migration does not break unrelated services.

Which hosting, CMS, and database access must transfer?

The owner needs administrator-level control of production hosting, staging, the content management system, databases, backups, logs, and billing. Access should use named accounts rather than a shared login. The handover must identify environments, regions, plans, renewal dates, limits, support channels, and any vendor-only action required to operate them.

Use named CMS accounts and least privilege

Create an administrator account for the accountable owner, confirm it can manage users, and use narrower roles for editors or support staff. WordPress documents the differences in its official roles and capabilities guide. Keep emergency administration separate from everyday publishing.

Identify every environment

List production, staging, development, database, object storage, cache, email relay, and scheduled-job environments. Record the URL, purpose, access path, data policy, and deployment source for each. A staging site that only the agency can reach is not a durable testing environment for the owner.

What code, design files, and licenses should you receive?

Receive the production-matching source code, full repository history, build instructions, custom themes or plugins, design source files, brand assets, fonts, image licenses, and a dependency register. Record who owns each asset, what may be modified or redistributed, where updates come from, and who pays each renewal.

Transfer the repository, not a zip file

For custom work, the business should own or control the repository organization and retain branches, tags, issues, pull requests, releases, and history. GitHub’s official repository transfer instructions explain what moves during a transfer. Verify that the production commit or release is identifiable.

Separate ownership from usage rights

A paid plugin, stock image, typeface, template, or SaaS subscription may provide a license rather than ownership. Build a register with the product, account owner, license terms, covered domains, renewal date, cost, update channel, and replacement risk. Do not assume an agency subscription can legally remain attached.

How should integrations and business data be handed over?

Inventory every form, mailbox, CRM, payment provider, ecommerce service, API, webhook, calendar, chat tool, analytics property, consent platform, and automation. For each, record account ownership, purpose, data exchanged, billing, permissions, secrets location, failure alerts, retention, export method, and the person responsible after launch.

Create an integration register

• System name, business purpose, owner, vendor contact, plan, and renewal date.
• Production endpoint, sending system, receiving system, authentication method, and data categories.
• Normal schedule, timeout, retries, duplicate handling, alert path, and manual fallback.
• Where configuration is stored and whether changing the website, DNS, or billing account affects it.
• How to export data and how access will be revoked when a vendor relationship ends.

Keep secrets out of handover documents

Deliver an inventory of secrets and their owners, not a spreadsheet containing plaintext passwords or API keys. Use a business-controlled password manager or secret store, rotate credentials after transfer, and remove obsolete access. The OWASP Secrets Management Cheat Sheet provides a practical lifecycle reference.

What proof should you demand for forms, analytics, and SEO?

Require end-to-end proof that forms deliver, notifications arrive, CRM records are created, consent behavior works, analytics events appear, and search tools remain accessible. Screenshots of settings are not enough. Test representative journeys from the public website, record timestamps and destinations, and assign remediation for every failed or ambiguous result.

Test communication and conversion paths

Submit every important form using controlled test data. Verify browser confirmation, email delivery, spam handling, CRM or ticket creation, notification recipients, reply routing, and retained consent evidence where applicable. For ecommerce, test payment, refund, tax, shipping, inventory, and order email paths before accepting the handover.

Transfer measurement and search permissions

Grant the business appropriate access in Google Analytics and Search Console, then verify the correct property, stream, domain, sitemap, and key events. Use Google’s official Analytics access-management guidance and Search Console users and permissions guidance to avoid confusing delegated access with verified ownership.

How should backups, deployment, and rollback be tested?

A handover should include automatic backup scope, frequency, retention, storage location, encryption, access, monitoring, and restore instructions. It should also document how code and content reach production, how changes are verified, and when rollback begins. At least one controlled restore or recovery drill should produce timestamped evidence.

Verify a restorable backup

Confirm backups include the database, uploads, configuration, custom code, and any external data required to recover service. Check that copies are not stored only beside production. Restore into an isolated location, verify representative pages and functions, record duration, and remove the temporary environment safely afterward.

Run the independent-operator test

Give a qualified person who did not build the site the approved documentation and access. Ask that person to deploy a harmless change to staging, verify it, roll it back, and locate production recovery steps. Any live coaching required from the original developer identifies missing knowledge or permissions.

What documentation and training make the handover usable?

Useful documentation explains the website’s architecture, environments, accounts, integrations, content model, publishing workflow, backups, deployments, monitoring, incidents, renewals, and support boundaries. Training should use the actual site and common tasks, then leave a recording, questions log, and updated runbook that a future employee can follow.

Build an owner-facing runbook

Include routine actions such as publishing, editing navigation, replacing media, reviewing form delivery, creating users, updating safely, reading alerts, restoring content, and contacting support. For each task, state prerequisites, steps, expected result, rollback, and escalation. Link to controlled sources instead of duplicating secrets.

Record training outcomes

Training is complete when the receiving team performs the agreed tasks, not when a developer presents slides. Record the session, store it in a business-controlled location, note unanswered questions, update documentation, and name the employees who can operate content, administration, analytics, and emergency escalation after launch.

How should credentials and vendor access be transferred safely?

Use business-controlled named accounts, a password manager or secret store, and a written access matrix. Confirm recovery factors before rotating credentials, migrate automation secrets carefully, test services after rotation, and revoke obsolete access only after continuity is proven. Preserve an emergency path that does not rely on the departing vendor.

Follow a controlled transfer sequence

1. Create or verify the business owner account and recovery methods.
2. Grant the minimum permissions needed to receiving staff and approved vendors.
3. Move passwords, keys, tokens, and certificates through an approved secure channel.
4. Rotate secrets that the former team knew and update dependent services.
5. Test logins, forms, deployments, integrations, backups, and monitoring.
6. Revoke obsolete users, sessions, keys, devices, and recovery methods.
7. Save an access review with owner, date, evidence, and next review date.

Do not destroy access prematurely

Removing the original team before new credentials, recovery factors, and automation secrets work can create an outage. Use a bounded overlap period with explicit roles and an end date. The receiving owner should approve revocation after tests pass, while high-risk accounts retain an audited emergency recovery method.

What should happen before final payment?

Before final payment, reconcile the contract against delivered scope, close critical defects, verify owner accounts, confirm code and asset rights, test integrations, restore a backup, execute deployment and rollback, complete training, approve documentation, define support, and sign a dated handover register with unresolved items clearly assigned.

• Match the delivered website to the approved requirements, designs, content, and change records.
• Confirm production, staging, domain, hosting, CMS, repository, analytics, and vendor accounts.
• Review invoices, renewals, license restrictions, warranties, and support exclusions.
• Test priority user journeys on real devices and production-like conditions.
• Record open defects by severity, owner, due date, workaround, and payment treatment.
• Save acceptance evidence and the final approved inventory in business-controlled storage.

Final payment terms belong to the contract, and ownership language may require legal review. The operational checklist supports acceptance; it does not replace professional legal advice about intellectual property, data processing, warranties, liability, or local law.

Which warning signs reveal vendor lock-in?

Vendor lock-in is likely when the agency owns essential accounts, withholds repository history, cannot explain deployments, stores secrets personally, controls renewals, provides no restorable backup, or remains the only administrator. Dependence can also hide in undocumented integrations, proprietary builders, nontransferable licenses, missing source files, and knowledge held by one person.

• The website lives inside a vendor account that cannot be transferred cleanly.
• The business has CMS access but no registrar, DNS, hosting, database, or billing control.
• “Source code” means a zip export without history, build instructions, or matching production version.
• Only the original developer can deploy, renew licenses, clear cache, or restore service.
• Forms and automations use personal mailboxes, keys, phones, or recovery addresses.
• No successor operator can complete routine tasks with the delivered documentation.

Not every managed service is lock-in. A company may intentionally retain a provider for hosting or maintenance. The distinction is whether the dependency, ownership, exit process, data portability, costs, and continuity risk are explicit and acceptable.

What should the post-handover support period cover?

A post-handover support period should define its start date, duration, channels, response targets, covered defects, excluded changes, training follow-ups, monitoring, escalation, and closure criteria. It should preserve operational continuity while the receiving team gains confidence, without turning undocumented build defects into an indefinite paid maintenance dependency.

Separate warranty or defect correction from new features, content work, platform updates, and ongoing maintenance. If continued support is useful, compare the scope with a documented website maintenance plan so responsibilities, evidence, response expectations, and renewal terms remain visible.

Website handover checklist summary

Accept the website only when the business controls identity, infrastructure, platform access, code, assets, licenses, integrations, data, analytics, security, backups, deployments, documentation, and recovery. Confirm those controls with real tasks and recorded evidence. A complete handover leaves a successor team capable, not merely a folder full of files.

• Domain, DNS, CDN, certificates, hosting, billing, and recovery methods belong to the business.
• CMS, database, staging, repository, design assets, and licenses are accessible and documented.
• Forms, email, CRM, payments, APIs, analytics, and search properties pass end-to-end tests.
• Backups restore, deployment works, rollback is understood, and monitoring reaches the right people.
• Named operators complete routine tasks using the runbook and training materials.
• Open defects, support terms, renewal dates, and future ownership are written and accepted.

Website handover FAQ

These answers address the decisions owners most often face at project close: when handover planning begins, whether administrator access proves ownership, what documentation matters, how to test independence, and whether payment should wait. Exact contractual rights vary, so combine operational evidence with qualified legal advice when needed.

When should website handover planning begin?

Begin during contracting and discovery. Name the accounts, deliverables, owners, formats, acceptance tests, training, support, and exit requirements before development starts. Update the register whenever scope or architecture changes. Waiting until launch makes account ownership, license restrictions, missing source files, and undocumented integrations expensive to untangle.

Is WordPress administrator access enough?

No. Administrator access controls WordPress content and users, but it does not necessarily control the domain, DNS, hosting, database, repository, backups, email delivery, analytics, payment services, premium licenses, or billing. A durable handover maps and verifies every layer required to operate, recover, and move the site.

Should the business own every account?

The business should directly control essential identity, infrastructure, data, billing, and recovery accounts whenever the platform supports it. Some managed services may remain provider-operated by agreement. In those cases, document delegated rights, export options, continuity, costs, support, termination, and the practical exit procedure before accepting the dependency.

What is the best website handover acceptance test?

Ask a qualified person who did not build the website to complete agreed routine and recovery tasks using only approved access and documentation. The person should publish safely, test a conversion, inspect analytics, identify integrations, deploy to staging, restore a backup, and explain escalation without live vendor coaching.

Can final payment be withheld until handover is complete?

Payment rights depend on the signed contract and applicable law. Operationally, businesses should define handover deliverables and acceptance criteria before work begins, record unresolved items, and follow the agreed payment process. Consult qualified counsel for disputes, intellectual-property questions, material defects, or obligations that the contract does not resolve clearly.

How can LeWebsite help with a website handover?

LeWebsite can audit a handover package, map missing ownership and access, test critical journeys, document integrations, verify backups and operational procedures, or prepare a site for a successor team. The goal is evidence-backed control and continuity, whether LeWebsite built the website or is taking over an existing project.

Review LeWebsite’s web development services and WordPress development services, or contact LeWebsite with the platform, current vendor arrangement, and delivery date. A useful first review should identify what the business controls, what remains dependent, and which tests can close the gap.