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.
Ownership gaps are easier to resolve while the delivery team and project context are still available.
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
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.
Create an account and dependency register
Do not rely on a screenshot of browser bookmarks. Create a register with one row for every external dependency:
- service and purpose;
- organization owner;
- billing owner;
- primary and backup administrators;
- authentication method and MFA status;
- renewal or expiry date;
- where recovery instructions are stored.
Include domain, DNS, hosting, repository, CMS, database, email delivery, analytics, consent, monitoring, scheduling, CRM, forms, fonts, images, and paid plugins where applicable.
The register should point to secrets; it should not contain raw passwords, API keys, or production environment values. Transfer those through the organization’s password manager or secret store, verify access, and rotate shared credentials after the transfer.
Test the handoff with an independent operator
The person who built the site knows too much to validate the documentation objectively. Ask a team member who was not responsible for delivery to complete a small operating task:
- sign in using company-owned access;
- publish or preview a safe content change;
- find the latest deployment and error logs;
- locate form-delivery evidence;
- explain how to restore or roll back;
- identify who approves an emergency change.
Record where that person becomes blocked. Those gaps are the real handoff backlog.
For high-risk systems, also verify a break-glass path: what happens if the primary administrator is unavailable, the vendor account is removed, or the deployment fails during an urgent change. Do not wait for an incident to discover that recovery depends on one personal account.
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.
Attach open issues to that sign-off. A known accessibility limitation, pending DNS transfer, temporary vendor account, or missing license record should have an owner and due date. “Accepted with open items” is more useful than declaring everything complete when it is not.
The final record should distinguish delivery acceptance from ongoing support. State the support window, response channel, included fixes, and what becomes new scope. That prevents handoff from becoming an indefinite informal retainer.
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.
