WordPress took the opposite road from Drupal: no decade-scale major migrations, just a steady stream of core releases that mostly auto-apply. That’s why there’s no “WordPress 7 crisis” — and why WP sites fail differently: not in big bangs, but in small pieces.

Where WP sites actually break

The core update is rarely the problem. The problem is the stack on top: a plugin abandoned by its author, a theme customized directly (so it can never update again), PHP versions aging under the whole thing, and page builders with their own compatibility weather. Each update cycle rolls dice across every plugin — most sites carry dozens.

The maintenance that matters

Real WordPress care isn’t “updates on” — it’s staging-tested update rounds (so the dice roll happens where users can’t see it), a plugin inventory that gets shorter over time, PHP kept current, and backups proven restorable before anyone needs one. The contract red-flags checklist applies double to WP plans: “minutes of edits” bundles are how a site ends up technically maintained and actually abandoned.

When a WP site needs a rescue

Same signs as any platform: the person who built it is gone, the admin password is a mystery, updates stopped out of fear. The rescue process is platform-agnostic on purpose — WordPress sites are half the practice. And if your stack is so tangled that every update breaks something, that’s not a personality trait of WordPress; it’s a fixable architecture problem, and the fix is usually removal, not addition.