WordPress Website Handover Checklist When Changing Agencies

Quick answer: a WordPress website handover is complete only when the business can control the domain, hosting, DNS, WordPress, code, licenses, analytics, backups and recovery process without depending on the outgoing agency. Use named owners and acceptance tests instead of treating a folder of passwords as a handover.

This checklist is for companies changing agencies, bringing support in-house or moving a client site to a new maintenance partner.

Assign a business owner before the handover begins

Name one person who can approve access changes, confirm ownership and accept the final transfer. The outgoing and incoming technical teams can perform the work, but the business should control the decision and the final account relationships.

Set a transition window with:

• a start date and target acceptance date;
• a freeze or approval rule for production changes;
• named contacts at both providers;
• a method for escalating urgent incidents;
• the date on which outgoing access will be removed.

1. Confirm ownership of the domain and infrastructure

The business should know who owns and pays for every service that can take the website offline. Record the account owner, billing contact, renewal date and recovery method for:

• domain registrar and registrant details;
• DNS provider and nameservers;
• WordPress hosting account;
• CDN, firewall and proxy services;
• SSL certificate management;
• transactional email and SMTP;
• business email if it shares domain or DNS dependencies.

Do not transfer a domain casually during a website handover. First confirm renewal status, registrar lock, recovery email and the effect of any DNS changes.

2. Transfer WordPress access with named accounts

Create named administrator accounts for the business owner and incoming provider. Avoid sending a shared administrator password in a document or email. After acceptance, remove accounts that no longer require access and reduce roles for users who do not need administration capabilities.

WordPress roles control what users can do, including publishing, plugin management and user administration. Review the official WordPress roles and capabilities before changing access.

Record:

• all administrator accounts and their owners;
• editor, author and contractor accounts;
• two-factor authentication requirements;
• application passwords and integration users;
• emergency password-recovery ownership.

3. Create a technical site inventory

The incoming team should receive more than the WordPress URL. Export or record:

• WordPress, PHP and database versions;
• active and inactive plugins and themes;
• custom plugins, must-use plugins and child themes;
• WordPress Multisite configuration, if present;
• scheduled tasks and external cron jobs;
• server-level caching and object caching;
• staging and development environments;
• known errors, compatibility risks and temporary fixes.

WordPress provides an exportable technical summary under Tools > Site Health > Info. The official Site Health documentation explains the configuration areas included, but the export should be supplemented with business context and credentials.

4. Transfer source code and the deployment process

Determine which files are generated, which belong in version control and which are managed directly on the server. The incoming team needs access to the current source of truth, not an old repository that no longer matches production.

Include:

• repository organization and administrator;
• active branches and release tags;
• deployment commands or continuous-delivery workflow;
• SSH, SFTP and hosting file access;
• build tools and supported runtime versions;
• environment variables and secret ownership;
• staging-to-production approval steps;
• rollback procedure.

Do not paste production secrets into the handover document. Transfer them through an approved credential system or create replacement credentials for the incoming team.

5. Document plugins, themes and licenses

For every paid theme, plugin or external service, record the product, purpose, account owner, license limit, renewal date and payment owner. Decide whether the license belongs to the business, the outgoing agency or must be replaced.

Identify tools connected through the previous agency’s master account. These may continue working after handover but fail at the next renewal or lose access to updates. Use the business plugin inventory guide to evaluate whether every dependency is still required.

6. Transfer analytics, SEO and marketing systems

Website ownership extends beyond WordPress. Confirm administrative access and ownership for:

• Google Analytics and Google Tag Manager;
• Google Search Console and Bing Webmaster Tools;
• advertising pixels and conversion platforms;
• cookie consent and privacy tools;
• form destinations, CRM and marketing automation;
• call tracking and scheduling systems;
• structured-data or feed-management tools;
• social profiles that publish through WordPress.

Verify that production conversions still reach the correct inbox, CRM, calendar or order system after access changes. Do not remove the outgoing provider until the business can see and administer the measurement accounts.

7. Take and verify a complete backup

Create a handover backup that includes the database and required files, then confirm where it is stored and who can restore it. A backup controlled only by the outgoing agency is not sufficient after the transition.

The official WordPress backup guidance explains that the database and files form the complete site and should be recoverable together. Record the backup timestamp, storage location, retention and validation result.

8. Record DNS, email and integration dependencies

List every important DNS record and what it supports: website hosting, email delivery, verification, CDN, security, subdomains and third-party platforms. A handover can damage email even when the website itself still loads.

For integrations, document:

• API owner and purpose;
• where credentials are stored;
• webhook endpoints and expected events;
• test procedure;
• vendor support contact;
• credential rotation plan.

9. Document open work and known risks

Ask the outgoing provider for a list of unresolved incidents, temporary fixes, pending renewals, upcoming releases and work that has been approved but not deployed. Include links to tickets, relevant files and the current decision owner.

Separate facts from recommendations. The incoming team should know what is broken now, what may become a problem and what is merely an optional improvement.

10. Define acceptance tests

The business and incoming provider should test the journeys that matter before accepting the handover:

• public pages load through the expected domain and HTTPS;
• administrator login and password recovery work;
• forms deliver to the correct system;
• checkout, payment, email and customer accounts work;
• search, multilingual and membership functions work where relevant;
• analytics and conversion events are received;
• backups can be accessed and the restore process is understood;
• the incoming team can deploy and roll back a safe test change.

WordPress handover deliverables

Deliverable	Owner after handover	Acceptance evidence
Domain and DNS	Business	Account access and renewal verified
Hosting and CDN	Business or named provider	Admin access and support route verified
WordPress users	Business	Named accounts and role review completed
Source code	Business-controlled repository	Current production version and deployment documented
Licenses	Named account owner	Renewal and transfer status recorded
Analytics and SEO	Business	Administrator access and live data verified
Backup and recovery	Named maintenance owner	Complete backup and restore path confirmed
Open work	Incoming provider	Tickets, risks and priorities accepted

A practical transition sequence

1. Inventory: collect accounts, systems, owners and open work.
2. Provision: create business-controlled and incoming-team access.
3. Verify: test critical journeys, analytics and recovery.
4. Accept: sign off deliverables and unresolved risks.
5. Rotate: replace shared secrets and transfer billing where required.
6. Remove: revoke outgoing access after acceptance, not before.
7. Monitor: watch errors, forms, transactions and uptime during the transition period.

If the handover includes moving infrastructure, use the WordPress migration checklist. WordPress also recommends backing up files and the database before a server move in its official migration guidance.

Security during offboarding

WordPress hardening guidance emphasizes limiting access and maintaining recoverable backups. Review administrator accounts, hosting users, repository members, SSH keys, API credentials and password-manager collections during offboarding. See the official WordPress hardening guide.

Remove access only after the incoming team has verified control and the business has accepted the handover. Premature removal can turn a documentation problem into an outage.

Frequently asked questions

Who should own the domain after a website handover?

The business should control the registrar relationship and recovery contacts, even when an agency manages DNS or renewals on its behalf.

Should the outgoing agency provide all passwords?

The goal is business-controlled access, not necessarily reuse of every old password. Create named accounts and rotate shared credentials instead of placing secrets in a handover document.

How long should the transition period last?

It depends on complexity. A simple site may require days, while ecommerce, memberships or several integrated sites may need a controlled overlap. Set acceptance criteria rather than relying only on a date.

Can the outgoing agency delete its accounts immediately?

Not before the incoming team verifies access, recovery and critical journeys. Remove obsolete access promptly after formal acceptance.

What if the outgoing provider will not cooperate?

Start with the accounts the business controls: domain, DNS, hosting, billing and WordPress ownership. Preserve evidence, create backups where possible and prioritize restoring administrative control before nonessential improvements.

Transfer the incident response plan before offboarding so the incoming team knows the severity model, emergency contacts, containment authority and recovery tests from its first day.

After access and documentation are accepted, an ongoing WordPress WebOps model can give releases, incidents, performance work and technical requests one accountable workflow.

Turn the handover into an operating model

A successful transfer should leave the website with clear ownership, secure access, recoverable systems and a known path for future requests. Use a portfolio maintenance audit to find remaining gaps and document ongoing responsibilities in a website support SLA.

CodaStudio can provide ongoing WordPress maintenance, agency portfolio support or white-label maintenance after the handover.