The WordPress Website Handover Checklist

List the registrar, DNS provider, hosting, WordPress administration, business email, transactional mail, analytics, Search Console, source repository and connected services. Some may be managed in one dashboard, but each has a different operational role. Record the account owner, billing contact, renewal date and recovery process without placing working passwords in an ordinary project document.

Invite the correct business account and verify the required permissions by signing in. Where an organisation or role-based access feature exists, use it rather than sharing the developer's personal identity. Keep recovery codes and other secrets in the agreed secure system, and check that a departed contractor is not the only recovery contact.

Do not transfer a registrar account or change DNS as an unplanned handover experiment. First identify the provider's supported process and any domain-transfer restrictions. Domain registration, nameservers, website hosting and email routing are separate settings; changing the wrong one can interrupt email even when the website appears healthy.

Make a register of premium themes, plugins, fonts, stock assets and external subscriptions. Include the purchaser, licence terms, renewal owner and what happens if the subscription ends. A developer may legitimately use an agency subscription, but the continuing service and exit terms should be explicit rather than discovered after updates stop.

Ask which components can be transferred and which require a new purchase or a managed-service agreement. WordPress's GPL licensing does not mean every third-party service, asset or subscription has identical terms. Record the relevant vendor documentation and seek appropriate advice for contractual questions instead of assuming that receipt of files settles every right.

Verify update access in the intended account without exposing licence keys in screenshots. Check whether staging and production are both permitted under the selected plan. Include payment gateways and mail providers in the operational register even when they do not use a conventional plugin licence. The business needs to understand recurring costs as well as the initial build.

Request the custom theme and plugin source, a repository or complete versioned export, and any build configuration required to reproduce the deployed assets. Include child-theme changes and site-specific functionality. A zip of a rendered page does not replace the files needed to maintain a WordPress installation.

Have the receiving maintainer identify the deployed revision and follow the build or deployment instructions in a safe environment. Record required runtime versions, package installation commands and the destination of generated output. Credentials should be supplied through the approved secure configuration, not committed into the repository for convenience.

Identify database-held configuration that is not reproduced by the source alone, such as selected templates, Global Styles or plugin settings. Decide what is documented, exported or migrated through a supported process. The project brief guide helps connect these deliverables to the original scope so unresolved work stays visible.

Document what the backup contains, its schedule, retention and storage location. The database, uploads and custom code may have different recovery needs. A backup stored only beside the live files can be lost during the same incident. Confirm who can retrieve an independent copy and how access is recovered if the main dashboard is unavailable.

Ask for a controlled restoration into an appropriate isolated environment and record the result. Open representative pages and check important functionality there. Take care that restored sites cannot send customer emails or process live payments accidentally. An archive that downloads successfully has not yet proved that the application can be restored.

For a store or membership site, discuss data created after the last backup. A database rollback may remove orders or account changes. Agree who authorises recovery and how recent records will be reconciled. The WordPress backup strategy explains recovery objectives and the difference between retaining a copy and having an operable recovery plan.

Run a recorded session with the person who will maintain content. Ask them to change a heading, add an image with appropriate alternative text, publish a test article and undo a mistaken edit. Use the actual site's templates and controls rather than a generic WordPress video that does not match the build.

Explain which operations need a developer and why. Changing a global template, removing a plugin or editing a checkout setting may affect many pages. Give editors a short route for asking for help and identify the staging environment for changes that need review. Use named accounts with appropriate roles instead of giving every editor administrator access.

Deliver the recording and concise written instructions in a business-accessible location. Include image dimensions or content constraints that matter to the design, but avoid a manual so large that nobody uses it. A good handover lets the editor complete routine work confidently and recognise when a request crosses into technical maintenance.

Check the public site using the journeys agreed in the scope: navigation, search where present, forms, relevant checkout states, key downloads and missing pages. Test on representative mobile and desktop layouts and with keyboard navigation. For delivery systems, obtain permission for a clearly labelled test and verify receipt in the actual destination.

Distinguish local or staging checks from live checks. A local form test may use mocked delivery, and a staging payment can demonstrate the integration without proving a live settlement. Record the environment, date and result for each check, including anything still awaiting an external provider or business approval.

Keep unresolved defects, exclusions and accepted limitations in one list with owners. Agree the acceptance and payment process in the contract rather than inventing terms during the last call. A hypothetical review worksheet can make the evidence clear without pretending that an unchecked item is complete.

Before removing access, identify service accounts and integrations that must continue operating. A developer's personal account may have accidentally become the owner of a scheduled task or automation. Transfer responsibility through the provider's supported process and verify continuity before disabling the old connection.

Remove unneeded temporary users, revoke obsolete application credentials and review active sessions as appropriate. Rotate shared secrets through the agreed secure process when ownership changes. Check that monitoring and renewal alerts reach a maintained business address. Do not copy working credentials into the handover report as evidence of completion.

Finally, separate the defect period, maintenance plan and incident coverage. Record contact routes, supported hours, response expectations and the process for out-of-scope requests. A thirty-day review can be a useful agreed checkpoint, but it is not an automatic entitlement or a universal support standard. The maintenance plan guide helps define the ongoing work after the project formally closes.