The job rarely arrives as a project. It arrives as “our site has got slow”, or “we cannot update anything without something breaking”. Behind it sits a WordPress installation that has been running for eight years, and that nobody has had a full picture of since the developer who built it moved on.

It is one of the more common jobs in the WordPress world. It just gets described rarely, because it is not a new site with a before-and-after picture.

The first step is not to fix anything

The temptation is to get going: deactivate plugins, update the core, clean up the theme. That is also the fastest route to switching off something that turns out to matter.

The first step is working out what is actually in use. Which plugins do something the site actually shows. What page types exist, and who edits them. What happens on an order, a sign-up, a form – the whole way from click to email or database. It usually takes a day or two, and it is the best-spent time in the whole job.

The rule I work by is simple: do not touch anything until you know why it is there. Code that looks redundant is often somebody's solution to a problem documented nowhere.

What you usually find

Some patterns recur.

Plugins that overlap. Two caching plugins installed by two different developers. A gallery solution used on a single page nobody has visited in two years.

Plugins emitting competing metadata. The worst kind of overlap, because nothing visible goes wrong. Two SEO plugins each write their own title, their own canonical and their own Open Graph tags into the same document head, and the theme may add a third set on top. The page looks right in a browser – but Google gets contradictory signals about what the page is called and which URL is the real one. It is not one broken plugin. It is two working ones.

Changes made in the theme rather than a child theme. Which means the theme cannot be updated without losing them – and so it has not been updated. From there it spreads: with the theme standing still, nobody dares update WordPress or PHP either, and eventually the whole installation is held in place by something nobody can remember.

Tracking that runs around the consent. Google Tag Manager installed through one plugin while consent is handled by another. Separately they both work: the banner appears and stores the choice, and GTM loads its tags. They do not necessarily know about each other, so the visitor's choice in the banner is not turned into the behaviour you assume. It is the kind of thing you do not find by using the site normally, only by looking at what the browser actually sends.

Code nobody dares touch. A functions.php of 1,000 lines, most of it added by different people over several years. No comments, no history, because it was never in git.

What I do about it

The order matters more than the tools.

1. A copy and version control. The installation has to live somewhere you can try things without touching what the client is using. And the code has to go into Git – not to be modern, but because it is the difference between “we changed something and now it does not work” and “we can see exactly what happened”.
2. What hurts now. If the site is slow, I measure why before optimising. If a security update has been deferred for two years, that matters more than tidying. The client should feel a difference before anyone starts on the work that cannot be seen.
3. One thing at a time. One plugin removed, the site tested, on to the next. It takes longer than clearing everything in one pass, but when something breaks you know what it was.
4. What makes next time easier. A child theme, so the theme can be updated. Changes moved out of functions.php to somewhere they can be read. A short note on what is where.

When it is not worth it

Sometimes the answer is to build new. It is when the theme is so far gone that clearing it up costs more than a new frontend, or when the content structure does not fit what the site has to do today.

But that is rarer than people think – and it is worth noting that whoever would build the new one is rarely the most objective judge of it. A site with eight years of content, indexing and inbound links has a value that does not appear in the codebase.

What it is really about

An inherited installation is rarely only a technical problem. It is also a question of somebody being able to answer what happens, and why.

That is what the work is: turning a system nobody understands into a system somebody can run. The code gets better along the way, but that is not the point. The point is that the next time something has to change, it is a task and not a risk.