Ask an operator why the updates are stacked up and the answer is almost always the same: “the last one broke the site.” So the next update becomes something to avoid, the backlog grows while you avoid it, and the growing backlog genuinely does make the next attempt riskier. The loop usually starts with a misnamed cause.
WordPress core is unusually conservative about backwards compatibility. Removing an old function takes years of warnings first, with a replacement in place long before the removal. Updating core alone rarely takes a site down. What breaks is not core — it is the combination.
Breakage comes from the combination
A running WordPress is a stack of layers, and each layer assumes things about the one below it. Some of those assumptions are documented promises. Others are merely observations — “it behaves this way today”. The second kind is where the trouble lives.
The concrete shapes are familiar. A plugin was calling an internal core function directly, and that function finally got tidied away. A theme pinned its CSS to a specific piece of markup core used to emit, and the markup changed. Two plugins hook the same point, the execution order shifts, and one of them silently stops doing its job.
In all three cases core kept its promise. What broke was something leaning on a thing that was never a promise. The distinction matters because the name you give the failure decides how you prepare for the next one.
A different diagnosis leads to different preparation
The left-hand diagnosis solves nothing and drags security patches into the delay with it. A published vulnerability becomes a target for automated scanning the day it is published, so postponing creates a fresh risk of its own. The right-hand diagnosis leads somewhere: raise one thing at a time, check in between, and stay in a state where you can name the culprit.
So what do you actually prepare?
If breakage comes from combinations, your preparation has to be about handling combinations. That is exactly what this series covers: an order to raise things in (part 2), a reversible state before you start (part 3), somewhere other than production to try it (part 4), a decision about what to automate (part 5), and verification and record-keeping at the end (parts 7 and 8).
One corollary is worth stating plainly: since the upper layers are the fragile ones, keeping fewer of them makes every future update easier. Deleting a plugin you no longer use is not losing a feature; it is removing a variable from the next update.
The maintenance cost of themes and plugins is covered further in the Themes & plugins archive, and if nobody has touched the site in years and a single jump feels too big, our optimization program takes the upgrade on as a job.
Next part
If combinations are the cause, order starts to matter. The next part covers what to raise first — core, plugins or theme — and why you check in between.