A good website handoff means the client can survive the developer disappearing tomorrow.
That sounds dramatic until somebody needs to renew a domain, move hosting, recover a password, update DNS, restore a backup, or figure out why the contact form stopped delivering messages after the developer who built everything moved on.
A finished website should not be held together by one person's memory. If the client still needs you just to prove they own their own site, the project is not done.
Put the business-critical accounts in the client's hands.
The cleanest setup is usually the client owning the account and granting the developer whatever access is needed to do the work. That applies to the domain, hosting, DNS, analytics, Search Console, payment services, business email, and anything else the business cannot afford to lose because one freelancer changed careers.
Sometimes a project starts under a developer-owned account because it was faster at the time. Fine. Temporary is not the problem. Forgetting to transfer it is the problem.
The domain is the front door. Nobody should need to hunt down an old developer to renew it.
Document the provider, plan, billing owner, renewal date, and who has admin access.
Cloudflare, registrar DNS, hosting DNS, whatever you used. Write it down.
Payment processors, booking tools, email platforms, forms, and customer systems belong in the handoff.
You can still have admin or collaborator access for maintenance. The point is that the client should not lose control of the business just because your account disappears.
Do not hand over a URL and pretend that is the whole project.
A client should receive the files and data required to maintain, move, or restore the website. What that means depends on the stack, but the principle is simple: give them enough to avoid being trapped on the current server forever.
- Current production source files.
- Database export when the website uses a database.
- Custom code, child themes, plugins, or modules created for the project.
- Logos, graphics, and image assets the client owns or is licensed to use.
- Build files or source files required to edit the site properly.
- Configuration notes that explain environment-specific setup.
Cool. Where are the files? Who owns hosting? Which account controls DNS? Nobody knows.
Less mysterious. Much more useful when somebody needs to move the site two years from now.
Transfer access like you expect the internet to remain full of terrible ideas.
Passwords should not live forever in a random email thread, a shared text file, or a screenshot somebody saved to the desktop. Use account invitations and delegated access when the service supports it. For credentials that actually need to be handed over, use a secure method and let the client change them.
Do not make your login the only key to the building.
The website should not stop working because a code is being sent to your old phone.
Recovery information is part of access. Treat it like access.
Do not collect permanent access just because you once built the footer.
If the setup only exists in your head, it is not documentation.
You do not need to write a 90-page manual that nobody will read. You do need a practical map of the parts somebody is likely to touch later. Good documentation answers the boring questions before they become emergency phone calls.
Include the normal workflow and anything that should not be edited directly.
Document destination emails, spam protection, storage, and any integrations.
CMS, plugins, dependencies, certificates, APIs, feeds, or anything else with a shelf life.
Write that down before the adventurous nephew with admin access finds it.
"Click Settings" is less useful than "This email address receives quote requests, and changing it will redirect new leads." Context survives interface changes better than screenshots alone.
A website can look self-contained while secretly depending on twelve other accounts.
Analytics, Search Console, email delivery, maps, booking systems, payment tools, CRM connections, social metadata, APIs, CAPTCHA, CDN services, and automation platforms are easy to forget because the customer never sees the login screen.
Make an integration list. For each service, record what it does, who owns it, who pays for it, which account has admin access, and what part of the website stops working if it goes away.
- Analytics ownership and property access.
- Google Search Console owner access.
- Email delivery and SMTP provider.
- Payment processor and webhook ownership.
- Booking, CRM, newsletter, or automation integrations.
- Maps, CAPTCHA, API keys, and external services.
"They can see the report" and "they control the property" are two completely different things.
Tell the client what renews before the renewal email becomes a jump scare.
Plugins, themes, fonts, stock media, hosting, domains, APIs, email services, premium integrations, and software subscriptions can all have recurring costs or license restrictions. Put the details in writing.
"Premium plugin" is not enough information six months from now.
Client license, developer license, agency license, or included hosting feature.
Nobody enjoys learning a certificate expired because the checkout stopped working.
Does the site stop working, lose updates, lose support, or simply keep running without new versions?
If an asset is licensed through your account and cannot legally be transferred, say that clearly. A handoff should make ownership clearer, not invent ownership that does not exist.
A backup nobody can find is just emotional support.
Before the project closes, make sure there is at least one known-good backup and the client knows where ongoing backups live. If restores are handled by the host, document that. If backups are stored somewhere else, document that too.
Use the finished production version, not some folder called final-final-REAL-this-one.zip.
Do not make your laptop the disaster recovery plan.
Who restores it, where the database goes, and which credentials are needed?
A zero-byte SQL dump is technically a file. It is not much of a rescue plan.
Define support before "real quick" becomes a second project.
Clients should know what happens after handoff. Developers should know too. Put the support window, maintenance arrangement, bug-fix policy, hosting responsibilities, response expectations, and future-work pricing in writing before everybody starts remembering the agreement differently.
Six months later, "anything" includes adding a store, rewriting the homepage, and integrating a CRM.
Everybody knows where the original project ends and the next one begins.
- How long is the post-launch bug-fix window?
- What qualifies as a bug versus a new request?
- Who handles updates and backups?
- Who handles hosting or domain support?
- How are future changes requested and billed?
Being indispensable sounds flattering until the website depends on you being alive, available, and remembering a password from 2024.
A professional handoff reduces dependency on the developer. That does not mean the client will never hire you again. It means they are hiring you because they want your help, not because you are holding the only login.
The client should be able to hire another qualified developer, move hosting, renew services, recover accounts, and understand the important architecture without needing your permission.
If the answer is no, there is still handoff work to do.
Before everybody shakes hands and disappears into the sunset, check the boring stuff.
Not every project uses every item below, but this is the list I would rather trim down than discover three months later that we forgot the one account controlling the entire website.
- Domain registrar ownership confirmed.
- Hosting ownership and billing confirmed.
- DNS or CDN ownership documented.
- Website administrator account created for the client.
- Production source files delivered.
- Database export delivered when applicable.
- Known-good backup created and location documented.
- Restore process documented.
- Analytics ownership transferred or verified.
- Search Console ownership transferred or verified.
- Form destinations and email routing documented.
- SMTP or email delivery provider documented.
- Payment, booking, CRM, and API integrations documented.
- Licenses and subscriptions listed.
- Renewal dates and billing responsibility listed.
- 2FA and recovery methods moved to the client.
- Temporary credentials rotated or removed.
- Developer access reduced to what is still needed.
- Content editing instructions delivered.
- Support and maintenance terms confirmed.
The website is only truly delivered when the client has control of what they paid for and enough information to protect it.
Website handoff FAQ
Should the client own the domain account?
In most normal client projects, yes. The domain is a core business asset. The developer can be granted access when needed, but the business should not depend on the developer's personal registrar account to keep its name online.
Should I give the client every password I used?
No. Give the client access to the accounts and credentials they own or need, preferably through delegated access, account invitations, password changes, and secure transfer. Do not hand over unrelated personal or agency credentials.
Do I need to give the client the source code?
That depends on the agreement, licensing, and what was built, but the handoff should clearly state what code and assets the client owns, what they are licensed to use, and what is required to maintain or move the website.
Should I remove my own access after handoff?
Remove access you no longer need. If you are staying on for maintenance, keep only the permissions required for that work. Permanent full access should not exist just because it is convenient.
What is the biggest handoff mistake?
Making the client dependent on one person for ownership, access, recovery, or basic knowledge. A handoff should reduce single points of failure, not create one with your name on it.
Good websites should be maintainable, movable, and understandable after launch.
Browse more Template Forge guides for practical website advice, or check out the template catalog if you need a cleaner starting point for the next build.