Taking over a WordPress site from another developer: a safe handover

Why a takeover starts with access, not changes

It is tempting to start a takeover with the visible problems: the slow homepage, the broken form, the outdated plugins. Resist that. If you change anything before you control the domain, the hosting and a backup, you are working without a safety net, and possibly on accounts that do not belong to you.

A lot of trouble comes from accounts set up in the previous developer's name. The domain renews on their card, the hosting sits in their reseller account, premium plugins run on their licence. Everything works until the relationship ends, and then a renewal fails or a licence is revoked.

So the first goal of a takeover is boring but essential: make sure the business owns everything the website depends on, and that a full backup exists before any change is made.

Timing matters too. The best moment to collect access is while the previous developer is still around and willing to help, even if the relationship is ending. A week of overlap, when both sides can answer questions, saves a lot of guesswork later. If the developer has already gone, the checklists below still apply; they just take longer to complete.

Ownership checklist

These are the accounts and assets that should belong to your company, not to an individual or a former provider.

• Domain and DNS. Find out where the domain is registered, who the registrant is and when it renews. The registrant should be your company. Note where DNS is managed, which may be a different service, and keep a copy of the current records.
• Hosting. The hosting account should be in your company's name and paid by you. Get the control panel login, SFTP or SSH access and the database credentials. If the site sits in the previous developer's reseller account, plan a move.
• Licences. List premium plugins and the theme, and check whose account the licences are on. Licences on the developer's agency account usually cannot be transferred and need to be bought again in your name.
• Google Analytics, Search Console and Tag Manager. Your company should be the owner or administrator of each property, not only a user. Add a company account as owner before the previous developer leaves.
• Email. If your business email runs on the same hosting or domain, write down where mailboxes are hosted and which DNS records they rely on. Email is easy to break during a takeover and painful to lose.
• SSL certificate. Check who issues the certificate and how it renews. Free certificates usually renew automatically on the host, but a certificate bought separately may expire unnoticed once the previous developer stops watching it.
• Third-party services. Email sending services, CDN, spam protection for forms, maps and fonts often run on separate accounts. List each one, whose account it is and what the site loses if it stops.

Also check who has administrator accounts in WordPress itself. Remove or downgrade accounts of people who no longer work on the site, once you have your own working admin login.

Technical checklist

Once ownership is clear, collect what you need to understand and safely change the site.

• A full backup. Files and database, stored off the server, made before any change. Confirm it can be restored, ideally on a separate copy of the site rather than over the live one.
• Error logs. Check the PHP error log and any WordPress debug log before you start. Errors that already exist are part of the inherited state, and it helps to know them before your own changes add new entries.
• Repository. If the theme or custom plugins live in a Git repository, get access or a full export. Without it, the live server is the only copy of the code.
• Staging. Find out whether a staging environment exists and how changes reach the live site.
• Plugin list. Export the list of plugins with versions, noting which are premium and which are custom.
• Custom code. Ask where custom functionality lives: the theme, a custom plugin, code snippets, or the hosting configuration. Any documentation is valuable, however brief.
• Integrations. CRM, newsletter, payments, booking systems and API keys. Note which keys are tied to the previous developer's accounts.
• Scheduled tasks and server settings. Cron jobs, redirects in the server configuration, caching layers and security rules are easy to miss, because they live outside WordPress. Ask for them explicitly.

If you want a second pair of eyes before you start, request a free website review. You get a report within 3 business days, with no obligation.

How to talk to the previous developer

Most handovers are friendly. Developers move on, and a clear, polite request gets a clear answer. Make it easy for them to say yes.

• Send one written list. Put everything you need in one email: accounts to transfer, credentials, the repository, documentation. Long chains of separate requests get lost.
• Ask for transfers, not just passwords. A shared password still leaves the account in their name. Ask them to transfer ownership or add your company as owner.
• Agree a date. Set a handover date and ask the previous developer to keep their access until you confirm everything works.
• Settle open invoices. If there are unpaid invoices, settle or agree them first. It removes the most common reason for delays.
• Stay factual. Even if the relationship ended badly, keep the conversation about the handover, not the past.
• Ask what they know. The previous developer often knows things no checklist will reveal: a plugin that must not be updated without a theme change, a form that sends to a specific inbox, a quirk of the hosting. Ask directly: “Is there anything that tends to break, or anything you always check after an update?” Five minutes of their memory can save hours of investigation.

If they do not respond, you are not stuck. Domain registrars, hosts and Google have procedures for proving ownership. They take longer, so start them early, and document every request you make.

Once the handover is complete, change every password that was shared with you, rotate API keys where possible and remove the previous developer's accounts. This is not a sign of distrust; it is simply how you close a handover cleanly.

The first two weeks of a WordPress site takeover

This is how I run a takeover as a fixed package: Takeover and clean-up, 2 weeks, €690 net one-off.

• Audit and access. I check plugins, the theme, PHP version, hosting and every account with access, and tidy up access so it is clear who can get into what.
• Backup before changes. Before I change anything, I make a full backup of files and database, kept off the server.
• Overdue updates. I bring WordPress core, plugins and the theme up to date, in stages when the backlog is long. Plugins that are abandoned or duplicate each other are flagged for replacement or removal.
• Fixes. I fix errors found in the audit. If a fix goes beyond the takeover, I quote it separately before I start.
• Speed. I improve loading speed where the audit shows clear causes.
• Report. You receive a report describing the state of the site and the next priorities.

During those two weeks the site stays online and your team can keep editing content. I agree with you in advance when larger updates happen, so they do not clash with a campaign or a busy sales period. In a typical takeover, the most time goes into the overdue updates: when a site has not been updated for a long time, I update in stages and check key pages and forms after each stage rather than all at once.

The report at the end is meant to be useful whether or not we keep working together. It lists what I found, what I fixed, what still needs a decision and what I would do next, in order of priority.

After the takeover, the site can move to ongoing care. Plans start at €190 a month on Care, and I recommend Growth (€390 a month including 4 hours) for sites that keep developing. Prices exclude VAT; contracts are monthly with 1 month's notice. Details are on the WordPress takeover and WordPress care pages.