End of Life or End of Support? The Difference Is Where the Risk Lives
Two dates arrive from every vendor, years apart, and most organisations treat them as one. The first is a sales announcement. The second is the one that leaves you running unpatched infrastructure.
Every vendor sends two notices about every product you own. They arrive years apart, they use similar language, and most organisations file them in the same place.
The first is end of life. The vendor stops selling the product and stops adding features to it. Nothing changes on the day it lands. The kit keeps running, the software keeps working, and the people who read the notice quite reasonably conclude that there is nothing to do this quarter.
The second is end of support. The vendor stops issuing security patches and will no longer take your call. That is the date that carries the risk, and it is usually somewhere between three and seven years after the first one.
Why the gap causes problems
If the two dates arrived together, nobody would confuse them. The difficulty is the interval.
An end of life notice is an event with no consequence attached. Nothing breaks. No service degrades. There is no incident to respond to and no budget line that suddenly needs defending. So it gets acknowledged and filed, and the organisation moves on to something that is on fire today.
Meanwhile the actual deadline sits several budget cycles into the future, which is far enough away that it belongs to nobody in particular. The person who read the original notice has changed roles. The refresh it implied was never costed, because at the time it was not yet urgent. And the notice itself is a PDF in a vendor portal, or an email in an inbox that has since been archived.
By the time end of support is close enough to feel real, the options have narrowed to the expensive ones.
What it costs when the gap is missed
The obvious cost is security. Unpatched infrastructure is unpatched whether or not anyone meant it to be, and a platform past end of support will not get a fix for the next disclosed vulnerability. Auditors know to ask about this, and the answer “we did not realise” is not one that survives the conversation.
The less obvious cost is financial. Refreshes discovered late become emergency refreshes. They are scoped against a date rather than a plan, they skip the competitive procurement that would have saved money, and they consume delivery capacity that was committed elsewhere. A migration that could have been a scheduled project across two quarters becomes a compressed one across two months, at a premium.
Then there is the quiet waste in the other direction: support contracts renewed on hardware the vendor no longer supports. The renewal is processed because the renewal is always processed. Nobody reconciles the contract against the support status of the thing it covers.
Why spreadsheets do not solve it
The instinct is to build a tracker. Someone exports the estate, adds two date columns, and circulates it.
It works for about a quarter.
The dates come from different places for every vendor, in different formats, on different schedules. Some publish machine-readable lifecycle data, some publish a PDF, some tell you when you ask. Keeping the columns current is a manual research task that nobody owns once the person who built the spreadsheet moves on.
More fundamentally, a spreadsheet does not do anything on your behalf. It records that a date exists. It does not raise the date twelve months out, when there is still time to plan a project rather than react to a deadline. It has no relationship to the support contract that covers the platform, the projects that depend on it, or the budget that would have to fund the replacement. Every one of those connections has to be made by a person, from memory, at the moment somebody thinks to ask.
That is the real failure. Not that the dates are unknown, but that knowing them changes nothing until someone joins them to the rest of the picture.
What tracking it properly looks like
The lifecycle dates need to live on the platform record itself, not beside it. End of life, end of support and end of extended support held against the deployed instance, with its vendor, version and environment.
From there, three things follow.
The dates raise themselves. Configurable alerts fire on approach, with enough lead time to scope a project, get it costed and get it into the plan. The point of the alert is not to announce that a deadline has passed. It is to arrive while the response is still cheap.
The dates connect to money. A platform approaching end of support has a replacement cost, a support contract that may or may not be worth renewing, and an operational cost that continues either way. When lifecycle data and financial data sit in the same system, the replace-or-extend conversation starts from numbers rather than instinct.
The dates connect to delivery. A refresh identified early can be grouped with others by site, vendor or cost centre, and converted into a project with a business case. Identified late, it is a line item in someone else’s emergency.
The distinction, stated plainly
End of life tells you a product has stopped moving forward. It is a commercial announcement, and it is a planning input.
End of support tells you a product has stopped being defended. It is a risk date, and it is the one that belongs in your governance reporting.
An estate where those two dates are recorded, connected and surfaced early is one where the refresh conversation happens on your schedule. An estate where they are not is one where the conversation happens on the vendor’s.
DemandFlow holds lifecycle dates against every platform instance, alongside the support contracts, costs and projects attached to them. If that sounds like a problem you recognise, platform lifecycle management is where it is handled, and IT asset management covers the same ground for the device estate.
