Website handover checklist: what you need to own and operate your site
The practical answer
A useful website handover gives the agreed owner control of the source, domain, hosting and connected services, plus a repeatable way to publish and recover. Ask for evidence of each capability, a named maintainer and clear exceptions. A working public URL alone does not demonstrate that you can operate the website after its original developer leaves.
Our Click and Mortar publishing workflow records the intended hosting project, an inspected release package, file hashes and the previous deployment. Those artifacts informed this proposed handover method. We are describing our own release operations, not claiming to have completed a client account transfer or tested every recovery scenario.
Define what ownership means before delivery
When comparing website proposals, ask what you will be able to do after delivery. Can your business appoint another developer, change its domain settings, publish an update and recover the previous version? Those are separate capabilities. A designer can deliver excellent pages while leaving an essential service attached to an account nobody in your business controls.
Write an operational inventory before the final handover. Give every asset an intended owner, an operator, a recovery contact and a verification step. A managed service can be a reasonable arrangement if the responsibilities and exit process are explicit. Record any components that cannot be exported or transferred. This checklist evaluates practical control; it does not determine contractual intellectual-property ownership.
For an AI-assisted build, include the source repository and reproducible build instructions. A chat transcript may explain decisions, but another maintainer still needs the actual code, dependency lockfile, asset provenance and the commands used to produce the deployed version. Keep instructions concise enough to follow without replaying months of conversations.
Use an ownership and operation matrix
The following matrix is a proposed acceptance worksheet. It is not a record of transfers we performed for a client. Adapt it to the services the website actually uses, and ask the responsible person to demonstrate each agreed check in an appropriate test environment.
Record the account or organization name and role, not its password. Store sensitive credentials in the agreed secure system and share access through supported invitations. An inventory should help a maintainer find the authorized access path without becoming a document full of secrets.
| Asset | Evidence to request | Unresolved risk to record |
|---|---|---|
| Source and build | Intended owner can access the repository; documented build succeeds | Missing assets, undocumented local dependencies or unclear usage rights |
| Domain and DNS | Named owner can administer the domain and identify DNS operator | Developer-only recovery or unclear renewal responsibility |
| Hosting and release | Correct project, production domain and deployment procedure identified | Preview mistaken for production or unknown runtime dependencies |
| Forms and integrations | Service owner and test procedure documented for each connection | Notification works but storage, renewal or authorization is unverified |
| Recovery and support | Previous working version, data backup procedure and responsible maintainer named | No restore test or undefined support boundary |
Check repository access and remaining permissions
GitHub documents that repository transfers require administrator access and that existing collaborators, webhooks, secrets and deploy keys can remain associated. Moving a repository is therefore not a clean reset of access. Inspect the resulting permissions and connected automation before calling the source handover complete.
For your acceptance record, capture who can administer the repository and which identities still need access. Have the incoming maintainer demonstrate a harmless change in a preview branch. Agree on access removal and credential rotation separately, with a recovery plan, rather than deleting a previous operator’s access while nobody else can deploy.
References: GitHub Docs: Transferring a repository
Treat hosting and connected services as separate checks
Vercel’s project-transfer documentation distinguishes transferred project resources from items requiring separate work. It says project environment variables are copied with exceptions for values defined in vercel.json, while integrations must be added again after transfer. Its domain behavior also distinguishes a root domain from delegated subdomain access. Read the current provider instructions for the actual configuration before a move.
Turn those differences into questions for your developer: which project serves the public domain, which service owns the form data, which account authorizes email delivery, and what stops working if an old connection expires? Do not assume that transferring hosting transfers every database, registrar account or third-party subscription.
Use a controlled preview for integration checks when available. Identify exactly what was observed: saved submission, accepted notification or verified downstream result. Our separate missing-email Field Note explains why these observations should not be collapsed into a single green success label.
References: Vercel: Transferring a project
Keep a release receipt that another maintainer can use
Our own publishing process creates a release manifest with file hashes and records the hosting target and previous deployment. That provides a bounded lesson for handover: identify the exact version the acceptance evidence describes. A folder called final or a screenshot of the homepage is insufficient to establish which files visitors receive.
Ask for a release receipt containing the production URL, source snapshot, build instructions, deployment identifier, included changes, important checks and previous working version. Keep private configuration references separate from public documentation. A second maintainer should be able to locate those records and explain the recovery sequence.
A previous deployment is only one part of recovery. If an update changes stored data or external settings, restoring old front-end files may not reverse those effects. Record whether database restoration and integration recovery have been tested, where those procedures live, and who has authority to use them. Mark an untested restore as untested rather than calling a backup file a proven recovery plan.
Finish with a short walkthrough and explicit exceptions
Use the final meeting to demonstrate the agreed operating tasks: locate the source, open the correct hosting project, identify the domain administrator, find the current release record and show how a content update reaches a preview. Choose a harmless example. Actual account transfers and production changes require their own approved scope.
For each check, record pass, unresolved or not applicable, together with a date and owner. Leave the meeting with a short exception list: an integration awaiting authorization, a restore procedure still untested, or a service retained under a managed agreement. Assign the next action and a responsible person rather than describing the whole site as handed over.
This differs from a pre-launch review. Launch review asks whether visitors can use the release; handover asks whether the agreed owner and maintainer can keep operating it. Use both when commissioning a website, and connect each promise in a proposal to evidence you can actually inspect.
Common questions
Is a ZIP file enough for website handover?
It may contain useful source or a static export, but it does not establish control of hosting, DNS, stored data or integrations. Match the delivered files to the agreed operating model and verify how the site is rebuilt and published.
Should every website account belong to the client?
Define the arrangement explicitly. Client-controlled accounts can make continuity easier, while a managed service may retain certain systems. Document access, renewal, support and exit responsibilities instead of assuming the same model fits every project.
Does a passing handover checklist prove the site is secure?
No. It records ownership and operational evidence. Security, accessibility, legal requirements and business outcomes require appropriate separate evaluation.
Sources and further reading
Primary references checked on September 23, 2026. Product claims belong to the cited provider; implementation recommendations reflect our judgment.
Field Notes / for developers
The next lesson, in your inbox.
A short, practical blurb for every new note, with a link to the full method. Web development, useful motion, automation, and lessons from AI-assisted builds. Up to three emails a week.
Developer notes, no sales sequence. Privacy · Prefer RSS?
Learn by building / with Tommy
Want a hand getting started?
If you want to get into AI web design or get better at vibe coding, I’d love to help you get started at no charge. Bring a project, a stuck prompt, or a question. I find I learn more by teaching others.
Book a free 30-minute learning callA practical conversation. No experience required.
AI assists research and drafting. Articles are checked for source support and clear distinctions between examples and verified work. Read our editorial policy. Suggest a correction.
