Website handoff is where good projects quietly fail. The site launches, the team celebrates, and then nobody knows who owns what. Months later, a login is lost, a domain expires, or a vendor can’t be reached.
A handoff is not a folder of files. It is a transfer of ownership, access, and operational knowledge. This guide is the checklist I use to make handoffs clean and low‑risk for service businesses.
It is always cheaper to fix ownership gaps at handoff than during a crisis for most teams.
Start with ownership, not access
Access is easy to grant. Ownership is the hard part. Ownership means you control the assets even if the vendor disappears. If you only have access, you are still dependent.
Ownership typically includes:
- Domain registrar account
- Hosting account or infrastructure
- Analytics account
- CMS or application admin
- Email and form delivery accounts
If any of those are under the vendor’s personal account, the handoff is incomplete.
The handoff checklist that prevents real damage
Here is the core checklist. It is deliberately short so it actually gets used.
1) Domain and DNS ownership
Confirm that the domain registrar account is owned by your company and that you control DNS. If the registrar is under a personal vendor account, transfer it.
This is the most common single point of failure. If you lose the domain, you lose the business.
2) Hosting and deployment access
You should have admin access to the hosting provider or the deployment platform. Ask for:
- Admin credentials
- Environment variables and secrets list
- Backup configuration
If the project uses Vercel, AWS, or similar platforms, make sure the account ownership is yours, not the vendor’s.
If you can’t log in without the vendor present, the handoff is not done.
3) CMS or app admin
Whether you use a headless CMS or a custom admin panel, you should control the admin user list. Vendors can keep their access, but you should be the owner.
4) Analytics and tracking ownership
Analytics is often forgotten. If the account is under the vendor, your historical data can disappear. Confirm ownership of analytics, tag manager, and any conversion tracking tools.
5) Documentation you can actually use
Documentation should be short and practical:
- How to update content
- How to publish or revert changes
- Where to find backups
- Who to contact for support
If the documentation is 80 pages and nobody will read it, it is not helpful. A short “operations page” is usually enough.
Security details that matter at handoff
Handoff is a security moment. Access is being transferred. Accounts are created. That is a risk.
NIST’s digital identity guidelines emphasize strong authentication and secure credential practices for systems that handle sensitive access. NIST SP 800‑63B
Practical steps:
- Require MFA on admin accounts
- Use a password manager and shared vaults
- Remove unused vendor accounts
- Rotate any shared credentials
These steps are not bureaucracy. They are protection against future chaos.
Email and form delivery should be owned
Service websites depend on contact and brief forms. If the email sending account is owned by a vendor, you can lose inquiries overnight.
Confirm ownership of:
- The sending domain configuration (SPF, DKIM, DMARC)
- The email provider account
- Any spam or deliverability monitoring tools
If you need a baseline for this, the email deliverability guide explains the basics.
Document the decision logic, not just the how‑to
A strong handoff includes more than step‑by‑step instructions. It includes the reasoning behind key decisions. That helps future teams maintain consistency.
Examples of useful decision notes:
- Why the navigation is structured a certain way
- What user objections the copy was designed to answer
- Why specific performance tradeoffs were chosen
This kind of context keeps future changes from eroding the strategy.
Don’t forget the “quiet” assets
Don’t forget the “quiet” assets
A lot of important assets live outside the site itself. Make sure these are included in the handoff:
- Design files (Figma or similar)
- Content source files
- Image licenses and usage rights
- Third‑party integrations (email, CRM, scheduling)
If you plan to iterate, you need these assets accessible. Otherwise every change becomes a rebuild.
SEO and visibility assets need ownership too
Marketing sites rely on search visibility. If you can’t access the search tools, you can’t diagnose issues or submit changes.
Make sure you have ownership of:
- Search Console (or equivalent)
- Sitemap and robots controls
- Redirect mapping file from the launch
This isn’t optional. If you lose those assets, SEO fixes become slow and risky.
Backups and rollback are part of handoff
Handoffs that skip backups create painful surprises. Ask for:
- Where backups are stored
- How often they are taken
- How to restore a previous version
If you can’t restore, you can’t recover from mistakes. That makes every future update riskier than it needs to be.
Verify licenses and usage rights
If the project includes custom fonts, stock imagery, or third‑party components, confirm that you have the right to use them. This is a quiet but expensive failure point. A license that expires can force a redesign later.
Ask the vendor to provide a short list of licensed assets and where the licenses are stored.
Handoff should include a post‑launch plan
A site is not finished at launch. That is why I include a small post‑launch plan in every handoff. It usually includes:
- Performance monitoring
- Security patch cadence
- Content update ownership
- A 30‑day post‑launch review
If you don’t plan this, you get a website that looks good but drifts out of date. The maintenance cost guide and retainer model posts explain why this matters.
A handoff should also protect your team
Your internal team should be able to operate the site without the vendor. That does not mean they need to rebuild it, but they should know where to go for changes.
If your team can’t update a simple page without a developer, the handoff isn’t complete.
The handoff meeting matters more than the document
You can write the perfect checklist and still fail if the handoff meeting is rushed. Schedule a handoff session that includes:
- A walkthrough of the CMS or admin
- A review of access and ownership
- Confirmation of support boundaries
This meeting is where confusion is revealed. Treat it like a delivery milestone, not a quick call.
Sign‑off should be explicit
Treat handoff as a formal milestone. Define what “complete” means and get a written sign‑off from both sides. That protects your team and avoids the slow drift of “just one more change.” A simple sign‑off email with a checklist is enough.
What to do if a vendor refuses to transfer
This is more common than it should be. If a vendor refuses to transfer ownership, treat it as a red flag. You should always be able to take your assets and move on.
If you need help, use the contact form and I’ll outline the steps for a clean transfer.
The simplest handoff test
Ask yourself:
- Can we publish a page without the vendor?
- Can we access analytics without the vendor?
- Can we move hosting without the vendor?
If any answer is “no,” the handoff is incomplete. Fix those issues before you sign off.
If you want a structured handoff plan, start with the project brief and I’ll map it to your stack. A short remediation sprint now will save you months of frustration later.
