The Cost of Deferring an Upgrade

info@muhammetsafak.com (Muhammet Şafak) — Sun, 18 Oct 2026 00:00:00 GMT

When I proposed moving from PHP 7.1 to a stable 8.2, the answer was short: “It works, so why bother?” The answer was right — nothing was broken that day. What had started to break was invisible: packages were dropping support for old PHP one by one, and the application was getting locked to 7.1.

“It works” describes today. The bill is issued by the days that follow.

The objection isn’t illogical, so I don’t wave it away. Spending time on something that isn’t broken looks like gaining nothing. You can’t refute a sentence that is right by arguing with the sentence; you have to come with a number. What follows is the accounting of what that sentence cost me: by which mechanism, in which line items, and how much of it I was able to measure.

How the Lock Gets Set

The lock wasn’t set in a single day; with every package update, one more door closed.

The mechanism is ordinary. A package drops support for the old runtime in its new version. Since the runtime hasn’t been upgraded, that version can’t be installed, and you stay on the old one. The same thing happens with the next package, then the one after. None of them raises an alarm on its own: the old version keeps working.

At some point no package is left that can be updated. I call this a dependency lock: the application is tied to the runtime, the packages to the application, and all of it together to 7.1. The way out is a single piece. I couldn’t move any package forward without upgrading the runtime; and without moving the packages forward, I couldn’t see what the upgrade would cost.

That’s why the lock is set unnoticed. Each door that closes is, on its own, a detail that can be deferred; no single package update looks big enough to make you say “we have to do the upgrade today.” Deferring the decision is reasonable every single time. The sum of reasonable decisions is being backed into a corner.

The worst thing about the lock is that it is silent. No error message says “another door closed today.” You notice it only on the day you try to update a package, while reading why the update won’t install.

The sign to look for in your own system is simple. Of the pending package updates, how many can’t be installed because of the runtime version? Every number above zero shows that a door has closed.

The Only Number I Have

On the day I proposed it, the job was a 1–2 day upgrade. While the lock was being set, each package update took a few hours. Both looked like small jobs, and that’s why deferring was easy.

A small job is a good candidate for deferral; “let’s finish the urgent thing first” fits into every calendar.

Once deferred, the job didn’t just grow; because it had piled up, it became a single piece. I had to skip versions: not from 7.1 to 8.2 step by step, but passing everything in between in one go. Dozens of breaking changes and deprecated methods lay ahead of me, and all of them had to be solved at the same time. A debt that could have been paid in installments turned into a single collection.

What the number really taught me isn’t the amount itself but the change in the kind of work. A few hours of package updates were piecemeal jobs that could be done in any order, on any day. Dozens of breaking changes are one indivisible job that has to be finished once started. Deferring didn’t only make the job bigger; it took away its flexibility.

This is the only number I have: a 1–2 day job, plus a few hours per package update. I have no measurement to set next to it for the total cost of deferring. I won’t set one, either; writing down a number I didn’t measure would be a worse argument than “it works, doesn’t it.”

Even so, this one number is enough to start a conversation. Against “it works, doesn’t it,” you can go not with “we’re gaining nothing,” but with “1–2 days now, dozens of changes in one go later.” To explain the difference between the two to a manager, a measurement isn’t essential; the direction of the comparison is enough.

How to produce the number is in part 7 of the series; which upgrade comes first is in part 3. Here I’ll say only this: if I could have put this comparison on the table that day, “it works” alone wouldn’t have been enough of an answer.

The Real Line Item on the Bill

We cleaned up the breaking changes; what we didn’t expect was the bugs that came after.

Breaking changes have a good property: the error message points to them. You draw up the list, close them one by one, and it’s over. This item is long but known: you can roughly estimate its size, place it on the calendar, and tell your manager.

The bugs weren’t like that. Some of them showed up in only a single case — a path that rarely gets triggered, a particular piece of data, a particular order. For a bug like that you first have to see it, then reproduce it, then find its cause. Each one is a separate investigation. Their fixes spread over months. One bug would close, and another would show up in a different case.

For planning, the two have to be written separately. Breaking changes are a predictable item; bugs are not. If you build the budget only for the first, the second lives outside the budget and inside the calendar.

That’s where the real cost is: the long tail. The price of the batch migration fits the calendar; the price of the tail doesn’t. On top of that, because I was carrying dozens of changes together, the source of every bug was one of dozens of candidates; telling which bug came from which change created a job of its own.

”It Works” Describes Today

Saying “there’s technical debt” isn’t enough against the “it works, doesn’t it” objection; the person across the table hears it as an opinion. To answer in business language, you have to break the risk into line items. Every deferred upgrade accumulates four:

End of support: once the runtime or framework is no longer maintained, no new fixes arrive. A set day on the calendar, a known date.
Time exposed to CVEs: for every CVE announced after the day support ends, no official patch arrives; unless your distribution or a paid extended support patches it, the hole stays in the system until you upgrade. The counter starts the day support ends and stops on the day of the upgrade.
Dependency lock: as packages are pinned to old versions, your update options narrow. Once the lock is set, the only way out is to move everything together.
Growing version gap: as the number of versions in between grows, so does the number of breaking changes and deprecated methods to solve in one go. In my case, that was dozens of items.

None of these produces an error today, and none shows on the monitoring dashboard; all of them will be paid tomorrow. For a manager the difference is this too: asking for budget for something broken is easy, explaining why something that isn’t broken will break is hard. That’s why naming the items works, because each one can be tied to a date, a counter, or a number.

The summary of the four items: “it works” describes today; risk is tomorrow’s balance-sheet item. The cost of upgrading is known, and you schedule the payment. The cost of deferring is unknown, and you don’t get to pick when it is collected.

When Do You Let It Go?

Not upgrading can also be a legitimate decision; in which cases, I’m leaving to part 8 of the series. My objection here isn’t to deferring, but to the deferral not being written down as a decision.

Deferring can be a conscious decision; but a decision that isn’t written down comes back one day as a surprise. A deferral with its date and reason written down is risk management; one without is just forgetting.

There is one thing you can do today: look up the end-of-support dates of the runtime and framework versions you use, and write them down somewhere. Even if the system has no inventory, two lines are enough: what’s running, and when its support ends. The next time someone asks “why?”, you’ll at least have a date in hand. If you also write next to the date how many versions behind the system will be by then, the question stops being “does it work” and becomes “when will we pay”; and the conversation starts there.

Ask yourself: if upgrading this system today were a 1–2 day job, would you do it? If the answer is yes, there’s nothing to gain by waiting; the job only grows.

The series continues from here: in part 1, the situations that trigger an upgrade; in part 2, the inventory and layers for seeing what will be upgraded; in part 3, the decision matrix; and up to part 8, the target version, prerequisites, rollout, and organization.

When you defer an upgrade, you don’t close the risk; you write the bill to the next day.