End-of-Life Software

Every piece of commercial and open-source software eventually reaches the end of its supported life. Vendors announce dates after which they will stop releasing security patches, fixing bugs or providing help, often in stages that move from full support to limited support and finally to none. Software that has passed these dates is described as end-of-life, or EOL. It may continue to run without any obvious problem, but new vulnerabilities will not be fixed and compatibility with other systems will gradually break down.

Most organizations run some end-of-life software, from old operating systems and databases to application versions that were never upgraded. Managing it is a constant part of technology planning, because support dates arrive on a schedule set by vendors, not by the organization. For enterprise architecture and IT finance, end-of-life software is both a risk to manage and a cost to plan for, since upgrading, replacing or paying for extended support all require budget.

Definition of End-of-Life Software

End-of-life software is any software version for which the provider has ended standard support. The related term end-of-support is often used interchangeably, although some vendors distinguish between the end of sales, the end of mainstream support and the end of all support.

End-of-life status applies to operating systems, databases, middleware, programming language versions, packaged applications and open-source components. It is a key input to technology lifecycle management and a common driver of legacy system modernization.

Common Lifecycle Stages

General availability is when a version is released and fully supported, with new features, bug fixes and security updates.

End of sale is when a vendor stops selling new licenses for a version, though existing customers remain supported.

End of mainstream support is when new features and non-security fixes stop. Extended support, where offered, continues security updates for a further period, often for an additional fee.

End of life or end of support is when all updates and assistance stop. After this point, the software receives no fixes, even for serious security vulnerabilities.

Risks of Running End-of-Life Software

Security risk is the most serious. Vulnerabilities discovered after support ends remain unpatched and are often actively exploited, since attackers know they will not be fixed.

Compliance risk follows, since many regulations and security standards require organizations to run supported, patched software.

Operational risks include incompatibility with newer hardware, browsers and applications, and difficulty finding staff or contractors with the necessary skills. Problems that arise may have no vendor fix at all.

Importance of End-of-Life Software in Enterprise Architecture

End-of-life dates create fixed deadlines in the technology roadmap. Upgrades and replacements must be planned and funded before those dates arrive.

They also affect many applications at once. A single database or operating system reaching end of life can require changes to dozens of applications that depend on it.

Tracking end-of-life status gives architects a clear, objective measure of technical health that business leaders understand. Unlike many measures of technical quality, a support date is not open to interpretation.

Cost Implications

Organizations facing an end-of-life date usually have four options: upgrade, replace, retire the application or pay for extended support.

Extended support can be expensive, with fees that often rise each year, and it is usually a temporary measure rather than a long-term solution.

Missing deadlines tends to raise costs. Rushed upgrades cost more than planned ones, and unplanned extended support contracts consume budget intended for other priorities.

Planning upgrades well ahead, and grouping them with other changes to the same applications, spreads costs across budget years and reduces disruption. Lifecycle dates should appear in the technology roadmap years in advance.

Common Challenges

Many organizations do not know which software versions they run across all applications, especially for components embedded in vendor products or custom applications. Open-source libraries inside custom applications are a frequent blind spot, since they are rarely recorded in asset systems.

Upgrades often compete with business projects for the same teams and budgets, and may be postponed repeatedly because they deliver no visible new features. Framing upgrades in terms of risk avoided and costs saved helps them compete for priority. They also reduce technical debt, which makes later changes cheaper.

Some applications cannot be upgraded easily because they depend on old versions of other software, creating chains of dependencies that must be addressed together.