End-of-Life Dates: The Deadlines Nobody Announces

The event that consists of nothing happening

Every other kind of release announces itself. A new version appears in a feed, a product goes on sale, a patch shows up in an update tool. End-of-life is the exception: on the day support ends, nothing is published, nothing changes, and the software carries on working exactly as it did the day before.

That is what makes these dates uniquely easy to miss and uniquely worth recording. There is no notification because there is no event — only the quiet cessation of future fixes. The system does not degrade. It simply stops being maintained, and you find out months later when a vulnerability is published against it and no patch follows.

The consequence is that end-of-life cannot be handled by reading a feed. It has to be stored ahead of time as a dated deadline and surfaced as the date approaches, which is a different mechanism from everything else in release tracking.

The vocabulary is deliberately confusing

Vendors use overlapping terms for meaningfully different states, and the differences determine what you actually get.

End of active support or end of standard support usually means no more feature work and no more routine bug fixes, but security fixes continue for a further period. End of security support or end of life means no fixes of any kind. End of sale means you can no longer buy it while existing installations remain supported. Extended support means fixes continue, usually behind a paid contract, sometimes at reduced scope.

The gap between the first and second of these is frequently years, and it is the difference between 'plan a migration' and 'you have a problem now'. Recording which of these a date refers to is as important as recording the date.

• End of active support — features and bug fixes stop; security fixes usually continue.
• End of security support / end of life — nothing further ships, at all.
• End of sale — no new purchases; existing deployments unaffected.
• Extended support — continued fixes, generally paid and generally narrower in scope.
• LTS — a branch designated for a longer support window than the normal release cadence.

Where these dates actually live

Support dates are almost never in the release notes, which is where people look. They live in a separate lifecycle page, a support policy document, or a table maintained by a product marketing team rather than an engineering one. Some projects publish them in the repository; many publish them only on a documentation site that is not in any feed.

For open source projects, the convention is usually a support policy stating a duration rather than a date — 'supported for eighteen months after release' — which means the actual deadline has to be computed from the release date and is never stated anywhere directly. That computation is exactly the kind of thing that never gets done in practice.

For commercial products, the dates exist and are published, but on a lifecycle page that changes without notice. Dates get extended, and occasionally brought forward. Checking once and writing it down is not sufficient; the record needs to be refreshed.

The transitive problem

Your exposure is not determined by the support status of the things you chose. It is determined by the support status of everything underneath them, and that stack is deeper than it looks.

A framework you use supports a range of language runtime versions. The runtime version has its own support window. The base container image the runtime ships in has another. The operating system inside that image has another again. Any one of these reaching end of life constrains the others, and the binding constraint is rarely the layer you were paying attention to.

The practical failure mode is discovering that a routine framework upgrade requires a runtime upgrade, which requires a base image change, which requires an operating system that your build tooling has not been tested against. None of those steps was hard. The problem is that they arrived together, triggered by a date that was known years in advance.

Storing deadlines instead of reading them

The mechanism that works is a forward-dated list, reviewed on a schedule. Every dependency that has a published support window gets an entry with the date and what kind of end-of-life it is. The list is reviewed quarterly — not to act on everything, but to see what is inside the next four quarters.

Quarterly is the right cadence because migration lead times are measured in months. A date twelve months out needs no action; a date four months out needs a plan; a date that has passed needs an incident. Reviewing quarterly means nothing gets less than two reviews inside its actionable window.

The reason to store these as data rather than in a document is that documents are not sortable by date and do not surface themselves. A deadline that requires someone to remember to open a file has the same reliability as no deadline at all.

The dates that move

Support dates are not immutable. Extensions are common, particularly for widely deployed versions where the vendor concludes that too many customers will be stranded. Occasionally a date is brought forward, usually when a version is retired early for security reasons.

Both directions matter. An extension is genuinely useful information because it buys planning time, and a great deal of unnecessary migration work has been done against a date that had already moved. A date brought forward is an urgent event by definition and tends to be announced with much less fanfare.

This is the argument for treating lifecycle dates as tracked records with a history rather than as facts written down once. What the vendor said in March and what they say in September may differ, and knowing that the date moved — and in which direction — is often more informative than the date itself.