Website Handoff Checklist: Transfer Control Without Breaking the Site

A website handoff is complete only when the client can control, recover and pay for every system the site depends on without borrowing an agency employee’s account. Sending a document full of passwords is not enough. The client needs durable ownership, named access, recovery methods, billing visibility and proof that the site still works after control changes.

The safest approach is to inventory first, transfer dependencies in order, rotate sensitive access and then run one acceptance test. That sequence protects a live site from an avoidable domain, DNS, hosting or account-recovery failure while giving both sides a clear finish line.

Ownership is different from login access

Login access answers, “Can this person enter today?” Ownership answers harder questions: Who can add or remove people, recover the account, change billing and survive the departure of one individual? A client who receives an administrator password but cannot reset it without an agency mailbox does not control the account.

Most platforms separate these powers. Google Search Console, for example, distinguishes verified owners, delegated owners, full users and restricted users. Google’s Search Console permissions update explains that an owner can add or remove users and that leftover ownership tokens require a separate check. Removing a person from a user list may not remove a verified owner until that token is removed as well.

WordPress uses roles rather than an ownership label. WordPress role documentation gives Administrators powerful site-management capabilities, including user management on a single-site installation. That still does not transfer the registrar, hosting account, payment method, source repository or recovery mailbox. Treat every platform as a separate control surface.

For a clean handoff, use a client-controlled business identity as the durable owner. Give agency staff named accounts with the least access their remaining work requires. Do not make a personal mailbox, shared employee password or agency phone number the only recovery path.

Build the handoff inventory before changing anything

Start with evidence, not memory. Record every service that can affect whether the site resolves, deploys, accepts business transactions, sends messages or can be restored. A short inventory exposes missing owners before an account change causes downtime.

Do not put raw secrets in this worksheet. Store each credential in the client’s password manager and record only the vault item name, platform URL, account owner and recovery path. If a cPanel backup belongs in the acceptance package, run one documented test restore; its receipt should prove that the archive was usable, not merely downloaded.

Inventory external dependencies as carefully as the web server. Contact forms may route through an SMTP provider, checkout may depend on payment webhooks, and marketing tags may belong to separate agency accounts. Ask which business event would disappear if each integration stopped, then assign an owner and test.

Transfer control in dependency order

Changing everything at once creates an attribution problem. Preserve the working path, establish client ownership and verify each layer before removing old access. A rollback is easiest while both parties can still reach the account.

Domain and DNS come first

Confirm the actual registrar, registered-name holder, administrative contact, renewal status and recovery address. For generic top-level domains, ICANN’s inter-registrar transfer policy status report documents the 60-day transfer lock that can follow a change of registrant. Do not casually change contact data immediately before a planned registrar move; ask the current registrar which transfer route and authorization credential it requires.

Moving ownership does not always require moving registrars. A client-controlled account at the current registrar may be enough when the provider supports an internal account push or change of registrant. Whatever route is chosen, preserve current nameservers and DNS records during the ownership change. Export the zone first, identify records managed elsewhere and schedule any live DNS edit separately.

Certificates deserve their own line. Determine whether TLS is issued by the host, CDN, control panel or an external certificate account. Voxfor’s WordPress SSL setup and verification guide is a deeper handoff when the new owner must confirm HTTPS, redirects and mixed-content behavior after control changes.

Hosting, source and deployment follow

Create or transfer the client’s hosting-account ownership without deleting the agency login. Confirm billing contact, renewal date, support PIN or authorized-contact rules, plan limits, server region and any provider-specific recovery method. When root, SSH or control-panel access exists, use named credentials and record who may rotate them.

Source code belongs in a client-controlled organization or account, not only on a developer laptop. GitHub’s repository-transfer documentation explains that transfer keeps repository content but can affect organization permissions and some linked relationships. After a transfer, verify teams, deploy keys, webhooks, environments, Actions secrets and the production deployment identity rather than assuming the repository URL is the whole system.

Deployment proof should be proportionate. A no-change build, staging deployment or documented release dry run can show that source, dependencies and credentials are available without pushing an unnecessary production change. Keep one known-good release reference and a rollback route.

CMS, business tools and data come last

Add a named client administrator to WordPress or the relevant CMS, sign in through a fresh browser and prove that password recovery reaches a client-controlled mailbox. Review agency users, plugin licenses, form destinations, SMTP ownership, analytics, Search Console, tag management, payment gateways and ecommerce integrations one by one.

For Google properties, granting viewer access is not ownership transfer. Give the client an appropriate administrator or owner role, verify it from the client account, then export the final user list. Store property and container identifiers so future teams can distinguish the live asset from abandoned duplicates.

Stores need an additional data check. Voxfor’s WooCommerce analytics guide can help the new owner confirm reporting scope, revenue fields and business access; a dashboard screenshot alone does not prove control of Analytics, payments or order data.

Secure the client’s new control plane

Once the client has proved access, replace shared or temporary credentials. Every person should use an individual account so changes remain attributable and offboarding does not require disrupting everyone.

Enable multi-factor authentication where available, then confirm at least two recovery routes that the client controls. CISA’s multi-factor authentication guidance explains why a second authentication method protects an account beyond its password; whichever method a platform uses, do not leave the only factor on an agency phone or inside an employee’s personal account.

A practical sequence is:

1. Add and verify the client owner or administrator.
2. Move recovery email, phone, billing and security notifications to approved client contacts.
3. Store new secrets and backup codes in the client vault.
4. Rotate shared passwords, API keys and deploy tokens that no longer need to persist.
5. Reissue agency access as named, least-privilege accounts only when continuing work requires it.
6. Remove obsolete users and old verification tokens after acceptance passes.

WordPress administrators should also confirm unique accounts, strong authentication and login monitoring. Voxfor’s WordPress brute-force protection guide provides a separate security checklist for 2FA, rate limits and WAF controls after account ownership is settled.

Rotation can break a live integration when a secret is embedded in a deployment system, webhook or plugin. Search the documented configuration and secret stores before revoking a token, rotate one class at a time, and test the dependent function immediately. Never revoke the last known recovery path until the replacement has been exercised.

Prove the site works under client control

Access screenshots are weak evidence. Run a small acceptance plan from outside the agency’s normal browser session so cached credentials do not hide a missing permission.

• Resolve the intended hostname and load the site over valid HTTPS.
• Sign in with the client’s CMS account and complete one safe content action.
• Submit a form and confirm both storage and delivery.
• For ecommerce, complete an approved test transaction or gateway test path and verify its callback and notification.
• Open hosting, registrar, DNS, Search Console and analytics from client-owned accounts.
• Retrieve one backup and prove the client understands where and how restoration begins.
• Confirm monitoring reaches a client contact and that the client can open a support request.

Voxfor’s WordPress post-migration QA checklist covers DNS, SSL, forms, checkout, redirects and SEO validation in more depth. A handoff is not a migration, but both events need user-path proof after control changes.

Record the date, tester, result and evidence for each check. If a check fails, restore the previous access state or keep both parties’ accounts active while the missing permission is repaired. Do not sign off with an unexplained exception such as “agency will handle later.” Assign an owner and deadline.

Define what happens after handoff

Control transfer does not decide ongoing responsibility. Write a separate operating boundary for hosting updates, CMS and plugin maintenance, backups, monitoring, security response, content changes, licenses, analytics, renewals and emergency support.

For each duty, name one accountable owner, expected cadence, evidence and escalation route. Voxfor’s managed-versus-unmanaged responsibility model helps separate infrastructure work from application, data and business duties.

Support terms should state what is included, how requests are authorized, the response channel, any retained agency access and when that access expires. Avoid vague promises such as “we will always be available.” A defined 14- or 30-day correction window may be useful, but its length belongs to the contract and project risk rather than a universal checklist.

Close only after the client passes the recovery test

The final handoff record should list every control surface, client owner, retained supplier access, recovery route, renewal, test result, exception and next review date. Both sides should sign the same version.

One test matters more than a folder of screenshots: ask the client to recover access to a critical account, identify the latest usable backup and explain how to contact the correct provider without agency help. When that succeeds and the live acceptance path still works, control has actually moved. Until then, the handoff is documentation in progress.