WordPress client handoff checklist: ownership, access and recovery
By AgencyHostHub Team
Published On June 14, 2026
A WordPress client handoff is complete when the client can access the services they own, understand their responsibilities and recover the site with the agreed support. Sending a list of passwords is not enough.
Use the checklist below for a planned handover. It is an operational template, not legal advice or a substitute for the terms of your client agreement.
1. Agree what is being handed over
Write down the services in scope, the receiving owner, the acceptance date and any period of continuing support. Separate ownership, billing and day-to-day access: those may belong to different people. Record unresolved issues instead of implying the site has no problems.
| Asset | Record in the handoff document | Acceptance check |
|---|---|---|
| Domain and DNS | Registrar, registrant contact, DNS provider and renewal owner | Client can access the correct account and identify renewal settings |
| Hosting and WordPress | Provider, site address, account owner and required role | Client signs in using their own account and completes an agreed task |
| Backups | Storage location, responsible person and restore instructions | Agreed restore exercise has a dated result or an explicitly recorded limitation |
| Email and forms | Mail provider, form destinations and support contact | Test message reaches the intended recipient |
| Analytics and search tools | Property identifiers and receiving account | Client confirms access to the right property |
| Code and licences | Repository, custom changes, licence owner and renewal terms | Recipient knows which assets transfer and which need replacement |
| Payments and integrations | Payment provider, account and billing owner, webhook or integration identifiers, and responsible maintainer; keep secret values in secure transfer storage, not this register | Recipient confirms access and an agreed sandbox or non-charging verification is recorded |
| CDN and security | Service and account owner, DNS/CDN/WAF configuration reference, and support contact | Receiving administrator confirms access and the documented settings |
| Design and brand assets | Design-file location, ownership and licence terms, and receiving account | Client can access the agreed files and knows any exclusions |
Keep passwords, recovery codes and API secret values out of this document. Record a reference to the agreed secure transfer location instead.
2. Give access that matches the job
Prefer an individual client account to passing around the agency’s login. WordPress distinguishes roles: an Editor can manage and publish posts, while an Administrator has wider site-management capabilities. Plugins and custom roles can change the details, so verify the actual permissions on the site. See the WordPress role documentation.
Agree which person handles administration and which people only need editorial access. Use the service’s supported account-invitation or secure sharing process. Ask the recipient to confirm access before removing the agency account; do not ask them to send passwords or recovery codes back by email.
3. Treat a domain transfer as a separate task
Changing hosting, changing an account contact and transferring a domain between registrars are different operations. Check the registrar’s current process before setting a cutover date. ICANN describes circumstances in which a transfer can be restricted, including some registration, transfer and contact-change situations; its rules are not a universal delivery-time promise. Consult ICANN’s registrant transfer FAQs and the relevant registrar instructions.
If the site is also moving hosts, plan DNS and email changes explicitly. Save a dated DNS record export and the agreed pre-change backup before a migration, and record a rollback owner. Do not combine an untested migration with access revocation on the assumption that everything will finish at once.
4. Demonstrate recovery and everyday tasks
WordPress recovery normally needs both database and file backups, as explained in its backup handbook. Record what your backup includes and which connected services need separate arrangements.
Walk through the client’s agreed routine tasks—for example, editing a page, checking form delivery and finding the backup contact. If a restore demonstration is in scope, use an isolated environment and protect personal information. Mark an untested restore as untested; possession of an archive is not a successful recovery demonstration.
5. Record acceptance, then close access
- Client confirms access to each in-scope service.
- Both sides record outstanding issues and who owns them.
- Billing and licence-renewal responsibilities are acknowledged.
- Support scope and end date are written down.
- Obsolete agency access is removed at the agreed point.
- Backup retention and deletion follow the agreed policy and applicable requirements.
Do not invent a standard retention period for every client. Contracts, privacy obligations and the purpose of retained data differ. Seek appropriate advice where those requirements are unclear.
A short acceptance message
“We have reviewed the asset register and confirmed access to the listed services. Outstanding items and their owners are recorded in the handoff document. The agreed support period ends on the stated date. Access removal and retained-data handling will follow the documented plan.”
Adapt that wording to the actual agreement; it is a checklist aid, not a legal release.
Documentation reviewed October 5, 2026. This guide describes a suggested process, not a client case study.
agency wordpress hostingagency wordpress workflowclientclient hosting managementmanagementmultisite managementreseller hosting
