Nothing happens on the day software reaches end of life. The server doesn't shut down. Users log in as usual. The reports still run. That's exactly why end-of-life software stays in place for years after its date: there's never a morning when it forces the issue.
The risk builds quietly instead, and it builds in several places at once. It helps to separate them, because each one has a different fix and a different owner.
- End of life rarely means the software stops. It means nobody is fixing it anymore.
- The risks are security, compliance, vendor support, compatibility, people and cost, and each one needs a different fix.
- Regulators have started asking for support dates directly. NYDFS 23 NYCRR 500.13 requires a support expiration date for every asset.
- Start with an inventory: every system, its version, its owner and the date its support ends.
End of life, end of support, and the date that matters
Vendors use the terms loosely, and they don't all mean the same thing. You'll see end of sale or end of marketing (you can't buy it new), end of mainstream or standard support (no new fixes as standard), extended support (often paid), and end of life (nothing at all).
The date that matters most is the one when the vendor stops shipping security fixes to you as part of normal support. Sometimes there's a paid extension behind it. IBM i 7.4, for example, left standard support on 30 September 2026, with a paid service extension running to 30 September 2029. We went through those dates in is IBM i end of life?. Sometimes there's no date of its own at all: .NET Framework 4.8 is supported for as long as the Windows version it runs on, which we covered in [.NET Framework 4.8 end of support](/insights/dotnet-framework-4-8-end-of-support).
So the question to ask about each system isn't "Is it end of life?" It's "When do the fixes stop, and what do we pay to keep them coming?"
End-of-life software risks, one at a time
Security: vulnerabilities that stay open
Once fixes stop, every newly discovered vulnerability in that software stays open for good. The exposure isn't limited to the old system either. Anything that connects to it or shares a network with it inherits some of the risk.
You can reduce that with compensating controls. Isolate the system on its own network segment, cut every connection it doesn't need, and add monitoring. That lowers the exposure. It doesn't remove it, and it adds work someone has to keep doing.
Compliance: auditors and regulators ask
Unsupported software comes up in audits, in customer vendor-risk questionnaires, and, increasingly, in regulation itself.
The clearest example is New York's DFS cybersecurity regulation. Section 500.13(a) requires covered entities to keep a complete, documented asset inventory, with a method for tracking each asset's "(i) owner; (ii) location; (iii) classification or sensitivity; (iv) support expiration date; and (v) recovery time objectives." Those requirements took effect on 1 November 2025.
If you're covered by that rule, "we're not sure when support ends" is no longer an acceptable answer. If you aren't covered, it's still a reasonable standard to hold yourself to, and your auditors may already be holding you to it. [Read 500.13 in full]
Vendor: nobody to call
When something breaks on supported software, you open a ticket. After the end of support, there's no ticket to open. Your team works it out alone, often at the worst possible moment. Third-party support firms exist for some products at a price, but they can't change the vendor's code.
Compatibility: everything around it moves on
The software doesn't change, but everything around it does. New operating system versions, databases, browsers, and drivers stop supporting it. So the old application ends up holding other things back: the server can't be upgraded because the application won't run on the new OS, and the database can't move because the application needs the old driver. One end-of-life system can pin several others in place.
People: fewer who know it
The longer software sits past its date, the fewer people want to work on it and the fewer can. If one person is effectively the support desk for an old system, that's a risk in its own right. We wrote about it in decision sothe one person who understands your legacy system.
Cost: the bill grows quietly
Extended support fees, old hardware kept alive because the software needs it, workarounds that someone maintains by hand, and audit findings that take time to answer. None of it shows up as one big line item, which is why it's easy to underestimate.
How to find what you're running
You can't manage end-of-life risk on systems you haven't listed. Build the inventory first:
- Every system and application, including the small ones that run a single process for a single team
- The version of each component that matters: OS, database, runtime, framework, and the application itself
- The vendor's support end date for each, taken from the vendor's own lifecycle page and not from a blog
- An owner for each system: a named person, not a department
For sources, start with your configuration management database if anyone trusts it. Then check server scans and license records. One of the most useful questions is to ask finance which software you still pay maintenance on and which you've stopped paying for. The second list is often the more interesting one.
If you're regulated in New York, use the five 500.13 fields as your columns. Even if you're not, they're a sensible template.
What to do about each system
With the inventory done, each system gets one of four answers:
- Upgrade within the platform. Move to a supported release of the same product. Usually the cheapest fix, when it's available.
- Pay for extended support and plan. Buy time deliberately, with a date by which the real fix happens.
- Isolate and contain. For systems that can't be upgraded yet, reduce their exposure and document the decision, so an auditor sees a managed risk and not an overlooked one.
- Replace or retire. For systems with no supported path, or that the business barely uses anymore.
To decide the order, look at three things together: how exposed the system is (internet-facing or holding sensitive data), how close the date is, and how much the business depends on it. A system that scores high on all three goes first.
Where an architecture and code review fits
Off-the-shelf products have upgrade paths. The hard cases are the custom applications built on platforms that have aged out, where nobody can say what an upgrade would touch until someone reads the code.
An architecture and code review answers that. Over 30 days, at a fixed price agreed before we start, we go through the codebase and architecture, map how the system fits together, find the hidden architectural debt, and flag the security and compliance gaps, including every component that's past or near its support date. The report says in plain language what is broken and what it would take to fix it. Your team can act on it, or we can do the upgrade as a separate project with its own scope and price.