Legacy WordPress: Fix Without Breaking

"Don't touch anything or it'll break." I've heard this from agencies more times than I can count. Here's how I approach legacy WordPress sites with the surgical precision they require.

Rule #1: Full Backup Before Anything

Before I change a single line of code, I create a complete backup: files, database, and server configuration. Then I set up a staging environment that mirrors production exactly. Every change gets tested on staging first. No exceptions.

Rule #2: Understand Before Changing

Legacy sites are full of "why is this here?" code. Before removing or modifying anything, I trace its purpose. That weird function in functions.php? It might be fixing a bug that took the previous developer a week to solve. I document what I find before I touch it.

The Stabilization Process

1. Audit: Full inventory of WordPress version, PHP version, themes, plugins, custom code, and server environment.
2. Risk assessment: Which components are most outdated? Which have known security vulnerabilities? What's the PHP compatibility situation?
3. Priority list: Security fixes first, then stability improvements, then performance optimizations.
4. Incremental updates: One component at a time, testing after each change. Never update everything at once.

The PHP Version Problem

Many legacy sites run on PHP 7.x or even 7.2. Upgrading to PHP 8.x is necessary for security but can break themes and plugins that use deprecated functions. My approach: run a PHP compatibility scan first, fix incompatibilities one by one, then upgrade PHP on staging to verify everything works.

When to Migrate vs When to Maintain

If the site uses a theme that's no longer updated, a page builder that's been abandoned, or plugins with known unfixed vulnerabilities — maintaining becomes more expensive than migrating. I provide an honest cost comparison so the agency can make an informed decision.