Taking over a WordPress site from another developer

Yes, someone else can take over almost any WordPress site. Do it in this order: secure the accounts, take a full backup, review what is there, fix the risks first, and only then start improving. Most handovers that go wrong skip the first two steps, change something on a site nobody has a copy of, and discover too late that the domain or hosting was never in the organization’s name.

This is the order we follow when a site built by someone else comes onto a care plan, and it works whether the previous developer is helpful, busy, or gone.

Step 1: collect every account

Before anyone touches the site, list every account it depends on and find out who holds each one:

The domain registrar, where the domain is registered and renewed.
DNS, if it is managed somewhere other than the registrar (a CDN or security service, for example).
Hosting, including any file access (SFTP) and the database.
WordPress administrator access.
Email sending, if the site sends through a mail service.
Payment gateways for registrations, donations or renewals.
Google Search Console and analytics.
Premium plugin and theme licences, which are often registered to the developer’s email, not yours.

For a .ca domain, the holder is the registrant, and the transfer process is built around that. To move a .ca domain to another registrar, it must be unlocked and you need its authorization code, requested from the administrative contact’s email on the domain record. The registrar has to supply the code within five days. A domain cannot be transferred within 60 days of being registered or transferred (CIRA, how to transfer a domain). CIRA’s rules also say a registrar may not hold up a transfer or a change of registrant over money owed to the registrar (CIRA, general registration rules).

If the domain or hosting is in a former developer’s or volunteer’s personal name, fixing that comes before anything else.

Step 2: lock it down

Once you have access, close the doors that belong to people who no longer need them:

Create a new administrator account in a named person’s hands, then remove old administrator accounts or reduce them to a lower role. WordPress administrators can do everything on a site, including installing plugins and managing other users (WordPress, roles and capabilities).
Revoke application passwords that belong to people or tools you no longer use. They are listed on each user’s profile and can be revoked one by one (WordPress, application passwords).
Change the passwords for hosting, file access and the database, not just WordPress.
Turn on two-factor authentication for administrator accounts.

This is not a comment on the previous developer. The Canadian Centre for Cyber Security’s baseline for small organizations asks for exactly this: administrator rights only where needed, accounts removed when people no longer need them, and two-factor authentication wherever possible (controls BC.12 and BC.5, baseline cyber security controls).

Step 3: take a full backup before changing anything

Back up both the files and the database. Downloading the WordPress folder alone does not capture the database, which holds your pages, posts, users and settings (WordPress, backups). Keep a copy somewhere other than the current host. If anything goes wrong in the next steps, this is the version you return to.

Step 4: review what is there

Now look properly. A good review covers:

Site Health. WordPress’s built-in tool, under Tools > Site Health, flags critical issues such as an outdated PHP version, plugins waiting for updates and failing background updates (WordPress, Site Health).
The PHP and database versions, against WordPress’s current requirements, which recommend PHP 8.3 or newer (WordPress, requirements).
Every plugin. Which are active, which are unused, which are out of date, and whether any has been closed in the WordPress plugin directory. A closed plugin can no longer be downloaded there, and the directory shows a notice explaining why (WordPress, plugin alerts and warnings).
Premium licences. Expired licences often mean no updates.
The theme and any custom code. Is there a child theme, a page builder, or code edited directly in files that the next update would overwrite?

Plugins deserve the most attention. Patchstack’s 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes, and six in WordPress core. It also found that 46% were not fixed by the time they were disclosed (Patchstack, State of WordPress Security in 2026). An unused or abandoned plugin is risk with no benefit.

Step 5: fix in order of risk

Put the findings in order and work down the list:

Anything that exposes the site or its data: known vulnerabilities, closed plugins, unsupported PHP, missing backups.
Anything that stops the site doing its job: broken forms, payments, registration.
Anything that makes it hard to maintain: unused plugins, code edited in the wrong place, duplicate tools doing the same thing.
Improvements, which can wait until the first three are done.

Update one thing at a time, check the site after each, and keep the backup from step 3 until the work is finished.

Step 6: move hosting, if you need to

If the site should move to new hosting, WordPress documents the steps: back up, move the files and the database, update the configuration and site address, replace old URLs, reset permalinks and test (WordPress, moving WordPress). Do it after the review, not before, so you know what you are moving.

What if the previous developer does not respond?

It is harder, but rarely impossible.

If your organization holds the hosting account, WordPress administrator access can be restored from the hosting side, through the database or command-line tools (WordPress, reset your password).
If your organization is the domain’s registrant, you can deal with the registrar directly.
If neither is in your name, gather whatever shows the organization paid for them, such as invoices and emails, and contact the registrar and host.

This is why the first question in any handover is who owns the accounts. Our article on who should manage your organization’s website has a short list of what the organization should always hold.

Disclosure: taking on sites we did not build is part of Managed Care. We review the site first, and if it cannot be looked after properly, we say what it would take.

If you are planning a handover, schedule a discussion.

Sources (checked 30 September 2026)