Navigating End-of-Life SKUs and Legacy Features in 2026

Nobody plans to be running unsupported software. It tends to happen gradually, a version gets older, a renewal gets pushed back, the migration project gets deprioritised because everything still technically works. And then a vendor announcement lands in your inbox and you realise the clock has been ticking the whole time.

2026 is an unusually dense year for end-of-life events across enterprise technology. MySQL 8.0, Node.js 20, Exchange Server 2016 and 2019, SQL Server 2016, SharePoint Server 2016 and 2019, Project Online, Office LTSC 2021, and Windows Server 2012's final Extended Security Update window, all hitting between April and October of this year. That's not a slow drip. That's a concentrated wave of deadlines that many IT teams are not adequately prepared for.

End of Support vs End of Life - The Distinction That Actually Matters

These two terms get used interchangeably, but they describe meaningfully different situations.

End of Support (EoS) means the vendor stops providing technical help, bug fixes, and security patches. The software keeps running, it just stops getting looked after. Every unpatched vulnerability from that point forward stays unpatched. Every new CVE that researchers find in the codebase gets added to an open list with no remediation coming from the vendor. For enterprise platforms that support customer operations, ERP systems, or CRM software development initiatives, continuing to run unsupported software can create significant operational and security risks. 

End of Life (EoL) goes further. The product is either fully discontinued or, in the case of cloud and SaaS platforms, literally shut down. Project Online becoming inaccessible after September 30, 2026 isn't a metaphor. The service stops. Data that wasn't migrated stops being accessible.

The practical difference: with End of Support, you're exposed and unpatched but the lights stay on. With End of Life, the lights go off. Both are serious. They require different responses and different timelines. Many organisations engage ServiceNow experts and enterprise modernisation teams during this phase to assess dependencies, prioritise migrations, and minimise operational disruption. 

For SKUs specifically, the picture adds another layer. End-of-Sale means a product is removed from the active sales catalogue, no new licenses, no new orders. But existing customers may still receive support under current contracts. When End of Support follows, that protection disappears entirely. When End of Life follows that, the product ceases to exist as a functioning service.

What Running Past an EOL Date Actually Costs

The most common reason organisations stay on legacy software past EOL is that nothing has visibly broken yet. The system is running, users are using it, and the disruption of a migration feels harder to justify than the cost of staying put.

That calculation tends to undercount the real exposure.

Security risk compounds daily. An EOL database or operating system doesn't stop accumulating vulnerabilities, researchers keep finding them, but fixes stop coming. MySQL 8.0 averaged 15 to 20 CVEs per year during its supported life. Those continue arriving after April 2026 with no patch response. Every day past the deadline is another day of unpatched exposure sitting in your environment.

Compliance frameworks treat EOL software as a control failure. PCI DSS 4.0 requires managing the full software lifecycle. Running unsupported software in a regulated environment is not a grey are, it's a documented gap that shows up in audits, affects certifications, and creates liability. Delaying action on legacy Oracle systems, for example, can cost between $300,000 and $500,000 per year per system in extended maintenance alone, without the security exposure factored in.

The modernisation gap widens. Legacy software frozen at EOL stops receiving new capabilities. Enterprise analytics modernisation initiatives, AI-powered automation, and connected workflow platforms assume a certain baseline of infrastructure currency. If your underlying systems are on unsupported versions, integration with modern tools becomes increasingly difficult, sometimes impossible without significant custom work.

The SKU Complexity Problem

SKUs, the specific product configurations and license structures that make up enterprise software purchasing, add a layer of complexity that pure version tracking misses.

When a software SKU reaches its retirement phase, they typically provide a migration path to a replacement offering. Palo Alto Networks' 2026 retirement of its CSSP program SKUs is a current example, specific partner license models are being replaced with MSSP Pay-as-you-go or Software NGFW Credits, with End-of-Sale from April 2026 and full End-of-Life from October 2026. For partners running services on those SKUs, the transition isn't just a software version change, it's a billing model, a licensing structure, and a service architecture change simultaneously.

Enterprise organisations managing large software portfolios often have multiple SKU variants of the same underlying product, purchased across different procurement cycles, with different support end dates. Without a centralised inventory that tracks SKU-level lifecycle dates, not just product families, the exposure is easy to miss until it's urgent.

A Practical Framework for Managing EOL in 2026

The organisations navigating this well aren't necessarily the ones with the largest IT teams. They're the ones with the clearest inventory and the most honest assessment of business impact.

Build a complete asset inventory with lifecycle dates. Not product families, specific versions, SKUs, and contract terms. Tools like endoflife.date track over 459 products with verified EOL dates. The information is available; the gap is usually in whether anyone has done the systematic mapping.

Categorise by criticality and exposure. Not everything reaching EOL in 2026 carries the same risk. A development environment running an EOL runtime is a different problem from a customer-facing application running on an EOL OS. Triage by blast radius, not just deadline.

Separate the "keep running" decisions from the "modernise" decisions. Some systems can be containerised or isolated to extend their useful life while a longer modernisation project runs in parallel. Windows Server 2012 workloads that can't immediately migrate to 2022 can potentially run on Azure with free Extended Security Updates as a bridge, but that's a bridge, not a destination. 

Long-term transformation strategies increasingly prioritise scalable cloud solutions that can support future workloads, AI capabilities, and evolving business requirements without repeated infrastructure overhauls.

Plan migration sequencing around dependencies. In real environments, the auth layer, workflow engine, or data export path often breaks before the core application does. Migrating one component without assessing what depends on it creates cascading failures that are more expensive than the migration itself.

The Modernisation Opportunity Inside the EOL Deadline

There's a way to look at EOL dates as forcing functions rather than just threats. A system being decommissioned creates a natural moment to replace it with something better, not just something newer.

Legacy system modernisation strategy that's driven by EOL timelines tends to produce better outcomes than modernisation initiated purely by ambition, because the deadline focuses decision-making. The business case writes itself when the alternative is unpatched CVEs and compliance gaps.

AI-powered workflow automation built on modern infrastructure behaves differently from automation layered on top of legacy systems at the end of their support life. The platform determines what's possible, and EOL systems increasingly limit what modern workflows can connect to, what data they can access, and how reliably they can be integrated with anything else in the environment.

The organisations using 2026's EOL wave as an opportunity rather than a crisis are the ones investing now in scalable cloud solutions that replace what's being retired with infrastructure capable of supporting the next ten years, not just the next patch cycle.

At Dotsquares, we work with organisations across the full lifecycle of these transitions, from legacy assessment through implementation and modernisation planning. If your 2026 EOL exposure hasn't been fully mapped yet, that's the right place to start.