Menu
What happens when a vendor announces the upcoming end of life for a critical piece of software? It’s time to bring out the business case template!
With no more development, no more patches, and no more support in the roadmap, it’s time to start thinking about your options. To upgrade or find a new vendor or… to do nothing.
Few people like the latter option since it means the problem will still exist and fester over time, increasing your business risk. However, a well-rounded business case must explore and understand what the do-nothing option means for your organisation. Perhaps it means delaying the upgrade. Does this level of risk fit within the risk appetite of the company? An informed decision needs a realistic view of the options, including choosing to do nothing.
Benefits of do-nothing
Yes, there are benefits to the do-nothing option. These include:
No direct capital spend is a simple benefit of the do-nothing case. But there are indirect benefits from retaining the status-quo as well. No change to technology, infrastructure and other integrated systems means no additional upskilling of your support staff, nothing new to onboard or update and no introduction of risk to your IT operations through new software to patch and manage. No change to technology also means your users, customers and other stakeholders do not have to invest time and effort into changing their current work habits and practices.
However, these benefits are quickly overshadowed by the drawbacks of choosing. It’s here that we’ll spend most of our time.
Increased support costs
As soon as software is at end of life, everything becomes more expensive. Organisations often offer extended support for a limited period after software end of life date. However, this typically comes with the caveat of higher rates, reflecting the challenges of supporting deprecated software. It’s up to you to measure the balance between potentially higher support costs over a normal lifecycle period, and the cost of an upgrade project.
Deferred cost
This is not to say it’s simply a question of one or the other. It may be in your best interest to defer the cost of an upgrade for the cost of extended support in the short term. After all, money doesn’t grow on trees, and every business has its own budget and roadmap to follow. Delaying an inevitable software upgrade or replacement can let you save money in the short-term and reinvest it in into other areas of your business. But can it outweigh the higher costs and elevated risks of running a deprecated version?
Loss of security patches
We all know the importance of patching – it’s a first line of defence for mitigating vulnerabilities in your environment. The vulnerability rating, the exposure and the exploitability of your software all play a part in your organisation’s resilience against a threat actor. So, what happens when the patches stop?
A negligible or low-rated vulnerability may be an acceptable risk, but what happens when you have an unpatched critical vulnerability? And how could this impact your internal security standards or compliance to legislation such as the Security of Critical Infrastructure (SOCI) Act.
Heightened security risk
Old software, old operating systems and old architectures mean increased security risk. End-of-life could leave you stuck using a deprecated protocol (I’m looking at you, TLS 1.1), an old operating system that can’t be patched, or architectures that can’t compete with evolving security threats. You can deploy mitigation techniques such as zero trust access, application control, and blocking internet macros but the risk will always still be there, albeit reduced. Not to mention the cost that comes with some of these mitigating techniques. And the more time passes after end-of-life, the more the cost and risk increases.
It’s time to bring out the risk matrixes and response plans. Is it better for your business to avoid, mitigate, share or accept the security risks that come with deprecated software? Perhaps the best response is a combination of two or more responses over time. It’s up to you to decide.
Looming Tech Debt
It isn’t just the software you need to consider when thinking about a do-nothing approach. Older software is often tied to older operating systems and architectures. Choosing to do nothing may leave you stuck running legacy operating systems, older versions of integrated software, physical hardware or locked in a datacentre infrastructure model because the software cannot run on anything newer. Suddenly your operations now have a higher risk of unrecoverable failure.
Heightened unrecoverable failure risk
How much would it cost your business to not have access to your software for a day, a week, a month, or even longer? Consider the consequences if you cannot recover it; a real possibility in any system. Losing access to software not only inhibits your employees’ ability to perform their roles but can also cause safety issues. Depending on the nature of your business, these safety issues can extend to customer or the general public. Reputational damage and an inability to meet regulatory requirements are also severe risks to consider.
Unrecoverable failure is a key risk to weigh when assessing the option to do-nothing in response to software end-of-life. No true business case would be complete without it. When all the pros and cons are listed, the risk matrices are filled, and cost estimates are completed, it’s time for your team to decide whether or not the do-nothing option is viable for your business.
Conclusion
When software reaches end of life, doing nothing may seem cost-effective but comes with serious risks—rising support costs, security vulnerabilities, and growing technical debt. A well-rounded business case must weigh these risks against your organisation’s strategy and risk appetite. Whether upgrading, switching vendors, or delaying, the key is making an informed decision that ensures long-term stability and security.
