A website is handed over only when the client can operate, recover, and move it without the outgoing vendor. A folder of source files or one hosting password is not enough.
Accept the dependencies in order: domain, DNS, hosting and deployment, source code and data, email and forms, measurement, then backups and recovery. Each step depends on the one before it. Accept each with evidence produced from a client-controlled account, not with a screenshot.
The eight ownership boundaries
| System | Evidence to receive | Acceptance test |
|---|---|---|
| Domain | Registrar, registrant organization, renewal date, billing owner | Client administrator can sign in and view renewal settings |
| DNS | Authoritative nameservers and zone administrator | Client can read the current records and export the zone |
| Hosting | Account owner, project, plan, billing and deployment access | A client-owned administrator can see the production deployment |
| Source code | Repository ownership, default branch and release history | Clone into a clean folder and build from the documented commit |
| CMS and data | Administrator role, export and media library | Export content and restore a safe sample |
| Email and forms | Sending domain, recipient, spam handling and provider | Submit a test and confirm both receipt and delivery logs |
| Measurement | GA4 property and Search Console owner access | Client-owned accounts retain administrator or owner control |
| Recovery | Backup location, retention, encryption and recovery contacts | Restore a sample without the vendor’s private device |
Google recommends structuring Analytics accounts around the legal entity that owns the data. Search Console also distinguishes an owner from lower permission levels. Give the client durable ownership first, then grant the vendor only the access needed for ongoing work.
Accept evidence, not screenshots
A screenshot proves what one person could see at one moment. It does not prove that recovery email, billing, or organization ownership has moved. Perform the important checks while signed in with a client-controlled account.
For each system, record:
- service and production URL;
- owning organization and primary administrator;
- recovery email and multi-factor authentication method;
- vendor roles that will remain or be removed;
- billing method and next renewal date;
- export, backup, and restore procedure;
- the date and result of the acceptance test.
Store the inventory in the client’s approved password manager or operations system. Do not paste passwords or recovery codes into the handover document.
The domain is the first dependency
Use an ICANN lookup to identify the registrar and current public registration data, but do not confuse public lookup details with account control. Confirm the registrar account, registrant organization, renewal payment, transfer lock, and nameservers directly.
If the client does not control the domain, every other handover remains fragile. DNS can redirect the website, email, verification records, and third-party services even when the source repository is safe.
Run one clean-room release
The strongest test is a small release performed from documented inputs:
- clone the repository into a clean environment;
- install the pinned dependencies;
- build using the documented command;
- deploy through the client-owned CI account;
- verify the canonical domain, forms, analytics, and rollback path;
- restore the previous release if the test requires it.
Record what still depends on the outgoing vendor. A hidden local file, personal cloud account, or undocumented manual step is an unresolved handover item.
Extra conditions for an AI-assisted build
Generated code does not replace the eight ownership boundaries. It adds failure modes that a working demo can hide. Add these acceptance checks when AI tools produced or scaffolded the site:
- Clean build: the documented commands build the site from a fresh clone without a local-only file, manual patch, or editor extension.
- Dependency inventory: packages are pinned, resolve from a public or client-controlled registry, and have a named owner for security and compatibility updates.
- Secret inventory: every environment variable, API key, and service account has an owner, storage location, and rotation method. If a secret was ever committed, rotate it rather than assuming deletion made it safe.
- Data migrations: run migrations against an empty database and an approved representative copy of the live structure; record the expected result and rollback.
- Generated-code review: a named reviewer reads authentication, form handling, file upload, and access-control paths instead of accepting them because they run.
- Licences: components, fonts, icons, images, and generated assets trace to terms that permit the client’s use.
- Deployment ownership: the build, hosting, billing, and any AI or automation service called by the live site have a documented owner and transfer path.
- Rollback and restore evidence: redeploy one previous release and restore one backup, recording the date, result, and elapsed time.
Generation speed is not an acceptance criterion. The test is whether another team can rebuild, deploy, and recover the site from the delivered accounts and documentation.
Sign off by exception
Do not finish with a vague “all files delivered” line. List every unresolved item with an owner, deadline, business impact, and temporary workaround. The handover is complete when the client can renew, deploy, measure, recover, and appoint a new vendor—not merely when a zip file has arrived.
Next action: book one hour with the outgoing vendor and run the clean-room release while both parties are present. The restore test turns the recovery row into a repeatable drill, while the website redesign SEO checklist covers URLs that move during a rebuild. To have IILL review the handover evidence, describe the current setup.
Need a clearer first step for your website?
Start with the situation and outcome. We will help define the scope and next step.