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.