End of life software in due diligence: how to inventory and plan

Buyers ask about end of life software because unsupported runtimes, frameworks and operating systems usually stop receiving security fixes, so each new flaw stays open. Build an inventory with support dates, rank by exposure, and present an upgrade plan with owners and quarters.

What counts

• Language runtimes and frameworks no longer maintained.
• Operating systems and base container images past support.
• Databases and middleware versions the vendor has retired.
• Libraries whose maintainers have stopped releasing.

Support terms differ by project, so check each vendor's own policy. Community trackers such as endoflife.date collect support dates for hundreds of products and offer an API, but confirm dates with the project itself before you quote them to a buyer.

Build the inventory

1. List every runtime and framework in production, with version.
2. Add base images and operating systems.
3. Record the vendor's stated end of support date.
4. Mark internet facing and customer data systems.

An SBOM and container scan cover much of this automatically. Asset discovery catches the forgotten servers.

Rank the risk

Rank by exposure, not age alone. An unsupported library inside an internal batch job matters less than an unsupported web framework on a public endpoint. Cross reference known exploited vulnerabilities for the versions you run.

Present a plan

For each item give:

• Current version and end of support date.
• Owner and target quarter.
• Interim control, such as network isolation or a web application firewall rule.
• Cost estimate in engineering weeks.

Buyers often price the upgrade into the deal. A concrete plan keeps the figure grounded.

Avoid these traps

• Reporting a vendor's extended support as full support.
• Counting a patched fork as supported without proof.
• Forgetting build tooling and CI images.

A short example plan

Suppose an inventory shows an old web framework on a public service, an operating system on three internal servers that is past support, and a database two major versions behind.

The plan could read: framework upgrade in the next quarter, owned by the web team, estimated six engineering weeks, with a web application firewall rule as an interim control. Servers migrate to a supported image in the second quarter, with the servers isolated on a restricted network until then. Database upgrade is scheduled in the third quarter after the framework work, since both touch the same release.

The point is sequencing and honesty. Buyers accept debt with owners, dates and interim controls far more readily than debt described as being handled soon.

Quick check

Sources

• endoflife.date

Last reviewed: 19 October 2026.