Flirting with Disaster: Why Using EOL & EOSL Software Is a Bad Idea

Key Points

• Software that has entered EOL or EOSL has lost some or all the developer’s support, respectively, introducing great risk for security vulnerabilities, incompatibility, and obsolescence
• Companies that stay on EOL/EOSL software tend to overpay consultants when trying to keep the solution functional and ultimately fail to address all critical gaps/vulnerabilities
• Enterprises that stay on outdated technology experience an average of 47% greater losses than those that stay current (Kaspersky)
• Data protection and cybersecurity are categories where software is mission-critical, highly complex (e.g., the need to support many third-party integrations and the need to evolve to address modern threats like ransomware), and therefore too risky to use past EOL/EOSL
  

  ---

End of Life (EOL) and End of Service Life (EOSL) are two terms that sometimes come into play when a software provider has decided to sunset a product.

In the data protection space, for example, there are two backup monitoring/analytics products called Servergraph (Rocket Software) and NetBackup OpsCenter (Veritas). These products entered “End of Limited Support” and EOSL, respectively, at the end of May 2024.

IT professionals understand these concepts enough to know they’ll have to find a replacement for a product the software provider has scheduled for EOL and EOSL, even if that date is far away.

But when does a replacement become necessary?

What are the fundamental differences between EOL and EOSL, and do they even matter in critical categories such as cybersecurity and data protection?

To address these critical questions, let’s first review what EOL and EOSL entail.

End of Life

Here are some implications for a product that has reached EOL, a phase that typically occurs before EOSL.

• No Further Development: The company will stop developing new features or enhancements for the software.
• Limited or No Support: Official customer support, including troubleshooting and technical assistance, will be reduced or completely discontinued. Users may no longer receive help with issues they encounter.
• No Security Updates: The company will cease to release patches or updates, including critical security fixes. This can make the software vulnerable to security threats.
• Compatibility Issues: The software may not be updated to work with new operating systems, hardware, or other software, potentially leading to compatibility problems.
• Encouragement to Migrate: Users are usually encouraged to migrate to newer versions of the software or alternative solutions offered by the company or other vendors.
• Cost Implications: Continuing to use EOL software might lead to increased maintenance costs as the user may need to hire external consultants for support or to ensure the software remains secure and functional.
• Risk of Obsolescence: Over time, using EOL software can result in performance degradation and reduced efficiency as it becomes outdated.

So, while it is possible to use a product that has reached EOL, doing so entails increased risk of security vulnerabilities, incompatibility, and obsolescence.

There’s also an interesting paradox that often happens when organizations choose to use software past EOL.

A decision to use software past EOL is based on perceived cost savings from not having to buy replacement software. (I.e., “I bought a perpetual license 10 years ago, and I don’t want to have to buy replacement software.”)

While this approach might make sense in some cases, for instance a graphic designer choosing to use design software past EOL, certain critical categories entail much more risk.

In cybersecurity and data protection (backup & recovery), for example – functions in which organizations simply cannot risk untimely software failures — the reality is that organizations that use software past EOL often spend more on (1) paying external consultants and developers in what often end as failed efforts to address critical gaps and issues that emerge past EOL, and (2), cleaning up the mess when gaps are exploited.

To the latter point, Kaspersky found that enterprises that use outdated technology experienced, on average, 47% greater overall losses (or about $389,000 more) per data breach. (source)

In the data protection and backup space, additional costs following a ransomware attack are often associated with recreating applications/systems that should have been backed up but weren’t – often due to inadequate backup monitoring capabilities. (Read how UnitedHealth Group’s multi-month ransomware debacle in 2024 illustrates this point.)

Now let’s look at EOSL, which typically follows EOL and marks the ultimate end of a product or product line.

End of Service Life (EOSL)

• Complete Discontinuation of Support: The company will no longer offer any technical support, troubleshooting, or customer service for the product. Users will not have access to official support channels for assistance.
• No Updates or Patches: There will be no further updates, patches, or bug fixes, including critical security updates. This can leave the software vulnerable to new security threats and bugs.
• Compatibility Risks: As new technologies, operating systems, and hardware are released, the EOSL product may become increasingly incompatible, leading to functionality issues or complete inability to use the software.
• Third-Party Support: Users may need to rely on third-party vendors or community forums for any necessary support, which may come with additional costs and varying levels of reliability.
• Increased Security Risks: Without security updates, the product may become a target for cyber-attacks, and any vulnerabilities discovered after EOSL will remain unpatched.
• Migration Urgency: Users are strongly encouraged to migrate to newer versions of the product or alternative solutions to avoid operational disruptions and maintain security and functionality.
• Potential Business Impact: Continuing to use EOSL software can lead to increased operational risks and costs, affecting the overall efficiency and security of the business.

Relative to EOL, using an EOSL product entails an even greater amount of security and financial risk due to the complete cessation of support. There are zero updates and patches, and if the product does not work for any reason – for example, if an integration to a third-party application breaks – you’ll be completely on your own and likely in a scramble to replace the software.

Should you use EOL/EOSL software?

The decision to use EOL/EOSL software comes down to your organization’s risk appetite and the software’s purpose and complexity.

• If the software is not serving a critical purpose and the software is simple enough that it’s hard to imagine it breaking even past EOSL, you might well take the calculated risk to continue using it past EOSL and hold off on spending money on a replacement.
• However, if the software does serve a critical purpose in your organization and is complex (e.g., software for data protection, cybersecurity, regulatory audit reporting, billing, etc.) the risk of complex software failing to work past EOL or EOSL is too great for most organizations to stomach. In such cases, it’s best to replace software ahead of both EOL and EOSL to mitigate preventable data loss, rash decisions (to build or buy), and hefty consultant fees when the unsupported software begins to fail.

Build vs Buy

A decision that enterprise IT decision makers often face in EOL/EOSL scenarios is whether to “build vs buy” replacement software.

As with the decision to use EOL/EOSL software or not, the decision to build in-house or buy off-the-shelf, supported software requires an understanding of the software’s function and complexity.

If the function is mission-critical (e.g, data protection or security) and the software is complex to maintain (e.g., software that requires supporting API-based integrations to third-party applications or staying current on security threats like ransomware), building your own software is rarely sensible for most organizations. While building a replacement in-house can give companies a sense of control from customizing the solution, the internal product management and engineering resources required to maintain/update complex software often result in far greater overall expenditures and less flexibility versus buying off-the-shelf software.

However, in rare circumstances when the software in question fits squarely into the development wheelhouse of your organization (e.g., you’re Google and you’re deciding whether to build or buy a piece of ad tech), there can potentially be a strong case to build your own software.

One thing to keep in mind is that internal subject matter experts (SMEs) and project champions come and go.

At Bocada, many of our enterprise data protection monitoring customers had initially built a tool in-house (prior to engaging with Bocada) only to later experience the compounding hidden costs of maintaining and updating the tool. In many such cases, a SME’s untimely departure or retirement was the final straw that compelled them to abandon the in-house tool and purchase off-the-shelf software from an established and specialized provider like Bocada.