End-of-life software: what happens when your vendor stops supporting it

End of sale, end of mainstream support, end of life: what's the difference?

Vendors rarely switch a product off overnight. Most run through a published lifecycle with distinct stages, and the terminology matters because each stage carries a different level of risk.

Microsoft's product lifecycle pages are a useful reference if you want to check where a specific product sits - see the Microsoft Lifecycle policy documentation for exact dates on Windows Server, SQL Server and similar products.

The security patching problem

Security researchers and attackers both continuously find new vulnerabilities in widely used software, including old versions. While a product is supported, the vendor issues a patch and the window of exposure closes quickly. Once it's end of life, that window never closes.

This is why end-of-life software is treated as a distinct category of risk by security bodies rather than just an operational inconvenience. The NCSC's guidance on end-of-life products sets out plainly why continuing to run unsupported software is one of the more preventable causes of breaches.

Compliance and insurance implications

Running unsupported software increasingly has consequences beyond the technical. Cyber insurance renewals now routinely ask whether all systems are on supported, patched versions, and a truthful "no" can affect premiums, excesses, or whether a claim is honoured at all.

Data protection obligations point the same way. The UK GDPR requires "appropriate technical measures" to protect personal data, and the ICO's own guidance treats unpatched, unsupported systems as a straightforward failure to meet that standard - see the ICO's guidance on security. If your business holds customer or employee data on an end-of-life system, that's a live compliance gap, not a hypothetical one.

• Insurance - insurers may decline claims linked to a known unsupported system, or load premiums once asked directly.
• Data protection - the ICO expects patched, maintained systems as a baseline; end-of-life software is hard to defend as "appropriate".
• Sector-specific audits - many supplier and accreditation audits (ISO 27001 among them) ask directly about support status of critical systems.
• Contracts - some B2B contracts and public sector frameworks now require confirmation that supplier systems are supported.

What to do before support actually ends

The lifecycle dates are published in advance for a reason - there's no need to be caught out. The practical response depends on how much time is left and how critical the system is.

1. 01Check the real end date, not the marketing date - end of mainstream support and true end of life are often years apart.
2. 02Establish what depends on the system and how disruptive a change would be.
3. 03Look at extended or paid security-only support as a bridge if you need more time, rather than as a long-term answer.
4. 04Plan the replacement or migration while there's still runway, rather than reacting after the fact.

If the software in question is a whole business system rather than a single product, this overlaps heavily with recognising a broader legacy system risk, and the fix is rarely a straight swap - see our approach to legacy system migration for how to move without downtime.

We handle this kind of assessment as part of our legacy software modernisation work: establishing exactly what's exposed, how urgent it is, and what a sensible sequence of changes looks like - rather than recommending a wholesale replacement by default.

If you'd rather talk through your specific system and timeline than read more lifecycle tables, get in touch and we'll give you a straight answer on urgency.