WordPress rescue from a failed agency: a senior developer checklist

A WordPress agency relationship can fail for many reasons. The agency closes. The contact moves on and is not replaced. The pricing changes in a way the client cannot accept. Communication breaks down. Whatever the reason, the client now needs a new developer to take over a site they do not fully control.

A clean takeover follows the same sequence every time. Skip steps and the rescue becomes a rebuild, because the inherited site rests on assumptions nobody documented.

If the site is mid-incident rather than mid-handover, read when to call an emergency WordPress developer first. Stabilising the live site has to come before a methodical takeover.

Step 1: Reclaim ownership of every credential

Domain registrar account. Hosting account. Database credentials. WordPress admin account. Email accounts used for the site. CDN account if any. Email service provider. Payment gateway account if WooCommerce. Analytics account. Google Search Console. The list is longer than people expect.

Each of those needs to be transferred to the client's ownership and then have passwords rotated. The previous agency's admin accounts should be removed entirely once the rescue developer has equivalent access.

Step 2: Take a clean backup before touching anything

A full database dump and a full file system archive, copied to storage that the client controls. This is the safety net for the rest of the rescue. If anything goes wrong in the next ten days, the backup is the rollback.

Verify the backup by restoring it to a local environment before relying on it. A backup that has never been tested is not a backup.

Step 3: Run the technical audit

WordPress core version. PHP version on the server. Plugin inventory and each plugin's update status. Theme inventory, including whether the active theme is a parent, child or custom. Custom code in mu-plugins, wp-content or the theme. Database table sizes. Cron job inventory. SSL certificate status. Backup configuration.

The audit produces a written document the client can read. It is not a list of code complaints. It is a summary of what they have inherited, what works, what is at risk and what is unusual.

Step 4: Stabilise the security surface

Remove unused plugins. Remove unused themes. Apply critical security patches. Remove or strengthen weak admin accounts. Verify two-factor authentication on the remaining admin accounts. Confirm that file permissions on the server follow current recommendations.

This is not optimisation work. It is closing the doors that the failed relationship left open. New work can happen later once these doors are closed.

The WordPress security hardening checklist goes through each of these in order, with the exact settings to verify on a freshly inherited install.

Step 5: Document the content model

Custom post types. Custom taxonomies. Advanced Custom Fields layouts. Custom shortcodes. Custom Gutenberg blocks. Plugin-specific custom fields. Every place in the WordPress admin where content can be added or edited needs a sentence of documentation explaining what it does and where it appears on the frontend.

This documentation pays back the first time a content editor asks why a field exists or where it appears on the site. It pays back even more when the next rescue developer needs to take over from the current one.

Step 6: Set up reliable backups and monitoring

Daily backups to offsite storage. Uptime monitoring. Notification when WordPress core or a plugin has a security update available. Error log review on a schedule.

This is the boring infrastructure that the failed agency probably stopped maintaining. Putting it back in place is what makes the site reliable from now on.

Step 7: Present a forward plan

The audit, documentation and stabilisation together produce a written forward plan with priorities ranked by risk and impact. The client gets to see what is recommended, why, what each item costs and what happens if it is deferred.

From there the relationship either continues on a retainer for ongoing care, or moves into a defined project to address the top items, or hands off cleanly to another developer who now has the full context. All three are valid outcomes.

What the client gets out of a proper rescue

A site they own. Credentials they control. A written understanding of what they have inherited. A list of priorities ordered by what matters. A reliable backup. A secure baseline. A relationship with a developer who knows what the site actually is.

For more, see WordPress services, what a WordPress site rescue actually involves or how to find a reliable WordPress developer.