The upgrade you keep postponing

Software has an expiry date, and it is published

Every language runtime, database and framework you depend on has a documented end-of-life date. After it, security fixes stop. The dates are public years in advance, and they arrive anyway, because nobody’s calendar has them in it.

As a shape rather than a specific list: Node.js major versions get roughly three years, with a long-term-support line; Python versions get five; Ubuntu’s long-term-support releases get five years of standard support; PostgreSQL major versions get five; Django and Rails maintain a small number of recent versions with a long-term line. The exact months change: look them up, and record the ones you depend on.

The fact that matters: an unsupported runtime does not stop working. It stops receiving patches. Your site runs exactly as well as before, which is precisely why it stays there.

The debt compounds, quietly

A framework upgrade skipped once is a week of work. Skipped four times, it is a rewrite, because the upgrade guides assume you are coming from the previous version, the migration tooling has been removed, the packages you depend on have moved on, and nobody remembers why the custom patch in the middle exists.

So the practical rule is counter-intuitive to how it feels: upgrade more often, in smaller steps, and never skip a major version if the project’s guide says not to.

A cadence that survives contact with real work

• Weekly, automatic: patch and minor version updates for dependencies, applied by a bot, merged when CI is green. Dependabot and Renovate are free and do this. Group them so it is one pull request, not thirty.
• Monthly, 30 minutes: read the failures. A minor update that breaks a test is a signal, not an inconvenience.
• Quarterly, half a day: one major upgrade (the runtime, the framework, or the database) chosen from the list, done properly with a staging run and a rollback plan.
• Annually, one hour: update the end-of-life dates for everything you depend on and put the next two into the calendar with a name against them.

That annual hour is the whole trick. The upgrade is not hard; being surprised by it is.

Database major versions are the one to plan

Application upgrades roll back. A database major version upgrade often does not, because the data directory format changes. Three honest options:

• A managed provider’s in-place upgrade. Simplest, and it needs a maintenance window measured in minutes, plus a tested backup taken immediately before.
• Dump and restore. Reliable, slow, and the downtime scales with your data size. Fine at a few gigabytes, painful at a hundred.
• Logical replication to a new instance, then a cutover. Near-zero downtime, more moving parts, and the approach worth learning once you are past the size where a dump is quick.

Whichever you choose, rehearse on a copy. Time it. Write the number in the runbook, because that number is your maintenance window.

Deprecations from providers arrive on their schedule

API versions get retired. Model snapshots get withdrawn. TLS versions and cipher suites get disabled by browsers. Payment providers change required flows to meet new regulation. Cloud instance families get deprecated.

Most of these come with months of notice, sent by email, to an address somebody set up in year one. Two habits: make sure provider notices reach more than one person and get read, and put every announced retirement date into the same calendar as your expiry list. This is the same discipline as the expiry lesson, applied to other people’s deadlines rather than your own.

Upgrading is also how you keep a site fast and cheap

It is easy to frame upgrades purely as risk avoidance, which makes them feel like a chore with no upside. In practice, runtime and database major versions routinely bring real performance and memory improvements, deprecate a workaround you were carrying, or add something that lets you delete code. A quarterly upgrade slot is one of the few maintenance activities that regularly makes the system smaller.

When you deliberately do not upgrade

Sometimes staying is correct: a library that is finished and unmaintained but does its job, a version whose successor removed something you need, a system nearing retirement anyway. That is a legitimate decision when it is a decision.

Write it down where the handover documents live: what you are staying on, why, what the risk is, and when you will look again. The difference between technical debt and technical negligence is whether somebody chose it on purpose and left a note.