Website Handover Checklist: Domain, Hosting and Admin Access

A website handover is not complete when you receive a password and the homepage loads. Your business also needs to renew the domain, restore the site, receive enquiries and recover access when a device or staff member is unavailable.

Use this checklist when a developer finishes a project, an agency contract ends or a new team takes responsibility for an existing website. Keep it as an operational record; contractual ownership and licence rights should be confirmed in the relevant agreements.

1. Make an account and responsibility register

List every service that keeps the site working. For each one, record the provider, account owner, billing contact, renewal date, recovery method and person responsible for maintenance.

Start with the domain registrar, DNS provider, hosting account and website administrator. Add email, CDN, storage, backups, analytics, Search Console, payment services, forms, transactional email and any external booking or CRM integration.

Store passwords and recovery codes in an appropriate password manager. The register should point to the secure record, not contain plain-text credentials in a widely shared spreadsheet.

Assign a business owner and a backup contact for critical services. An account that only one departing contractor can recover is still an unresolved handover item.

2. Verify the domain account and recovery route

Sign in to the actual registrar account and check the domain, expiry date, contact details, billing method and renewal settings. Confirm who can make changes and who receives renewal or security notices.

ICANN recommends protecting registrar accounts with strong credentials, multi-factor authentication and registrar locking where available. It also recommends a recovery email that does not depend on the domain itself. That helps avoid a circular problem in which a domain outage prevents you from receiving the message needed to fix it.

Do not assume a registrar transfer is necessary just because a developer is leaving. First establish control of the current account and clarify the intended account or registrant changes. If a transfer is required, follow the registrar's current process and check any applicable restrictions before planning dates.

Our domain transfer checklist covers the operational questions to ask.

3. Record DNS and email dependencies

Identify which service hosts the authoritative DNS zone. It may be separate from both the registrar and website host.

Record the current nameservers and export or securely document the DNS records. Mark which records serve the website, inbound mail, outgoing-mail authentication, verification and third-party applications.

Avoid “cleaning up” unfamiliar records during handover. A TXT or CNAME record may validate a business service, and an MX change can affect email while the website continues to load normally.

Test inbound and outbound email with an external address. Check the website's contact form separately: receiving ordinary mailbox mail does not prove that form notifications are delivered.

Where supported, invite named team members with scoped permissions. Cloudflare, for example, supports member policies that combine roles with account or resource scopes. Choose access based on the person's responsibilities.

4. Confirm hosting and website administration

Verify access to the hosting control panel and its support channel. Check the service name, renewal details, resource limits, backup settings and recovery options. Record any server or application tasks that the hosting provider does not manage.

For WordPress, create separate named accounts. On a single-site installation, the Administrator role has broad site-management powers; content staff may only need Editor access. A multisite network has additional Super Admin responsibilities. Choose the smallest role that supports the work, and verify that the business retains the appropriate administrative access.

Check that the website's administrative email reaches the right business contact. Test a password-reset flow for a designated account without removing the existing recovery path prematurely.

Ask for a short maintenance record: supported runtime versions, custom code locations, scheduled tasks, deployment method and known unresolved issues. If the project uses Git, confirm repository access and who can release changes.

5. Receive a backup and test the restore

A backup filename is not evidence that you can recover the website. Record what is included, where it is stored, how old it is and who can retrieve it.

A typical WordPress restoration needs both the database and the website files. WordPress's official backup guidance treats these as separate parts of the recovery process.

Restore the handover copy into an isolated test environment. Protect that environment from public indexing and disable real payment processing, outgoing customer messages and scheduled production jobs while testing.

Check a representative set of pages, images, forms and administrative actions. Document the steps and time required. Keep the original backup intact and fix missing components before marking the handover complete.

For a repeatable workflow, use our website backup and restore guide.

6. Transfer integrations and licence records

List paid themes, plugins, fonts, stock assets and external services. Record the licence holder, renewal responsibility and what happens if an agency subscription ends. Do not assume receiving the website files transfers a subscription or grants additional usage rights.

Check integrations one at a time. Identify the account that owns each API key or service connection, establish replacement access where necessary, update the integration and verify its function.

For WordPress REST API integrations, application passwords are separate credentials that can be revoked individually. Review the active entries and remove credentials that are no longer needed after their replacement has been tested.

Do not rotate every credential simultaneously without a dependency list. A staged change makes it easier to identify and recover a broken form, deployment or billing connection.

7. Check analytics and search ownership

Confirm that the business can access its analytics property and Search Console property, using the appropriate account and permission level. Save the property identifiers and document the verification method.

For Search Console, removing a departing verified owner from the user list is not sufficient if their verification tokens remain. Google's guidance explains that those tokens can let the person verify again. Review the former owner's verification methods and remove the relevant tokens while retaining the business's own working ownership verification.

Be precise: do not delete every TXT record or every verification file. Some may belong to current owners or other services.

8. Sign off, then remove obsolete access

Run the final check with the person who will operate the site:

• Sign in to each critical account using the business's own access.
• Confirm renewals, billing contacts and recovery methods.
• Submit a test enquiry and verify delivery.
• Check email, essential integrations and any checkout in its appropriate test mode.
• Retrieve the independent backup and review the restore record.
• Record open issues with an owner and an agreed next action.

Once replacement access works, revoke old accounts, SSH keys, application passwords and service tokens that are no longer needed. Check that routine operations still work afterwards.

Keep a dated handover record with both the completed checks and the unresolved items. A clear list of two known follow-ups is more useful than declaring everything complete while nobody knows who controls the domain.

Sources

• ICANN: Protecting your domain name and account
• Cloudflare: Manage account members
• WordPress: Roles and capabilities
• WordPress: Backups
• WordPress: Application passwords
• Google: Manage Search Console owners and permissions