End-of-Life Software: The Vendor Notice That Starts the Clock

The email reads like routine marketing: the vendor announces a new version and, in the fourth paragraph, notes that the version you run reaches end of support in eighteen months.

That paragraph is the most expensive sentence in the email. Unsupported software stops receiving fixes, and every newly found weakness in it stays open. The notice is not news to file. It is a countdown that has already started.

Organizations handle this well when end-of-life dates live in a register, each with an owner and a decision made early: replace, upgrade, or consciously mitigate.

TLDR

• Collect every vendor end-of-life and end-of-support date in one register.

• Start the replace-or-mitigate decision at least a year before the date.

• Treat 'still works fine' as irrelevant; support status is the issue, not function.

• If you must run past the date, isolate and document the accepted exposure.

• Review the register twice a year; dates move and vendors acquire each other.

The quiet inventory problem

Most companies cannot list the end-of-life dates for their core systems. The dates live in vendor portals, procurement emails and the memory of whoever installed the thing. Meanwhile, known weaknesses in unsupported versions are exactly what attackers scan for, because they know those holes will never be patched.

CISA's known exploited vulnerabilities catalog is full of entries affecting versions that no longer receive fixes. Running past end of support is not a neutral 'keep it working' choice; it is an accumulating exposure.

Build the register from procurement, not IT memory

Start with the contracts and purchase records: what did we buy, what version do we run, when does support end? Vendors publish lifecycle pages; pull the dates for your top systems and record them with an owner.

This fictional example shows a register excerpt. It is an illustration, not a real inventory.

System	Version	End of support	Owner	Decision due
Finance ERP	2019 release	Apr 2026	T. Nguyen	Sep 2025
Office suite	2016	Oct 2025	R. Alvarez	Aug 2025
Phone system	v9	Mar 2027	D. Osei	Jun 2026

One page, reviewed twice a year, beats a discovery project that starts the month a system goes dark.

Make the decision a year early

Replacing a core system takes longer than anyone budgets: selection, migration, testing, and the parallel run. A decision made twelve months out has options. A decision made two months out has an emergency purchase and a risky cutover.

For each date, the choice is one of three: upgrade or migrate on the vendor's path, replace with something else, or run past the date with documented mitigations. The third option is sometimes rational for low-exposure systems, but it should be a signed decision, not a default.

When running past the date is the answer

If a system must outlive its support, reduce what it can touch: isolate it on the network, remove its internet access where possible, restrict who can log in, and add monitoring. Write down who accepted the residual exposure and when the arrangement gets reviewed.

Patch management guidance from NIST frames unsupported software as a risk to be treated deliberately, with mitigations chosen in proportion to the exposure. Proportion is the key word: a print server and a payment system do not deserve the same answer.

The related discussion of a 90-day technology strategy is worth your time alongside this one.

Frequently asked questions

Who should own the register?

IT or the technology lead maintains it, but the decisions belong to the business owners of each system. The register just makes sure the decision happens on time instead of by surprise.

What about software with no announced date?

Record 'no date announced' and check twice a year. Also watch for the softer signals: a vendor that stops releasing updates, gets acquired, or stops answering. Those are early warnings without a formal date.

Is paying for extended support a good option?

Sometimes, as a bridge while a real replacement is decided and funded. It is a poor permanent strategy: costs rise each year while the underlying exposure stays. Treat it as buying time, and spend the time on the actual decision.

A Defensible Next Step

Ask your technology lead for the end-of-support dates of your five most important systems. If the answer takes more than a day, the register does not exist, and building it is this quarter's cheapest risk reduction. Book a Decision-Clarity Call if you want a template.