Plugin modernization
Modernizing software that is already installed everywhere is a different discipline from building something new, and most advice quietly assumes the second one. You cannot take the system down. You do not control the PHP version, the WordPress version, the host, or the other twenty plugins sharing the process. Every migration you write will meet production data you have never seen, on a site whose owner did not ask to be part of your rollout.
So the constraints invert. Migrations have to be additive, because a rollback has to be survivable without a backup. Features ship behind a flag and a percentage, because your staging environment is a fiction compared to the install base. Compatibility becomes an explicit, documented matrix rather than a hope, and deprecations get a runway measured in releases rather than weeks.
The rewrite deserves its own warning. It is almost always the wrong instinct, not because the old code is good, but because the value is in the accumulated context: the edge cases that code has absorbed over five years. These essays are about changing a mature codebase while it is awake, using the strangler-fig approach, so the system keeps working for the people already depending on it.
- You maintain a plugin or product with thousands of live installs.
- Someone has proposed a rewrite and you are trying to decide honestly.
- You need to ship a schema change without breaking sites you cannot test.
The case against the rewrite, and the strangler-fig alternative that lets you replace a system while it stays live.
Feature flags, staged percentage rollouts, and treating the host environment as the variable you watch hardest.
Additive-only schema changes, guarded backfills, and the rollback test that tells you a migration is safe.
Turning compatibility into an explicit matrix, with runtime guards for the versions and functions you do not control.
Modernizing something with real users on it?
Legacy plugin, a migration you are nervous about, or a rewrite decision you want pressure-tested. Happy to look at the specifics.
Get in touchOther people's writing that shaped it
- joelonsoftware.com · Joel Spolsky
Things You Should Never Do, Part I
Twenty-five years old and still the most useful thing written about the urge to rewrite. The argument is that the ugly code you want to delete is ugly because it encodes bug fixes you have forgotten about, and a rewrite throws that knowledge away along with the mess. If you maintain a plugin with an install base, read it before your next planning meeting rather than after.
- martinfowler.com · Martin Fowler
Strangler Fig
The practical answer to "we cannot rewrite it, so what do we actually do". New behaviour grows beside the old system and takes work away from it piece by piece, until the original can be retired. The part worth sitting with is the defence of throwaway transitional code: scaffolding you will delete later is not waste, it is what makes the risk affordable.
- semver.org · Tom Preston-Werner
Semantic Versioning 2.0.0
The specification itself, which is short and which most people quoting it have not read. The value for plugin work is not the numbering scheme, it is the definition of a breaking change: anything that alters the public API, where the public API includes behaviour other people have come to depend on, not just function signatures.
Building something where this kind of work matters?
I'm in GMT+6 and work async-first, so your timezone is never a reason not to reach out.
Get in touch