Find End of Life (EOL), End of Service Life (EOSL) & Support End Dates

EOSL.date is a simple and free online tool for checking End-of-Service-Life dates for your IT infrastructure components, particularly useful for planning hardware and software upgrades. If you're managing enterprise IT assets, understanding EOSL dates is crucial as they mark the final end of manufacturer support for products.

Hey there! I'm Subash Geetha Krishnan, Tech Lead for Nimble Storage at HPE Services Storage Support. After over 15+ years of wrestling with enterprise storage solutions, one thing became crystal clear - finding End-of-Life (EOL) or End-of-Service-Life (EOSL) dates shouldn't be this hard.

The problem? EOL and support information is scattered everywhere, often buried in PDFs or hidden in complex support matrices.

Please note that EOSL.date aggregates data from various publicly available sources, including vendor announcements, official documentation, and industry reports. While we strive to keep the information accurate and current, we always recommend cross-referencing with official vendor resources for the most up-to-date details.

EOL, EOS, and EOSL are three different stages in an IT product's lifecycle — and each one changes what your vendor will and won't do for you. They are not interchangeable, and the confusion is made worse by the fact that Cisco, HPE, Dell EMC, IBM, Juniper, NetApp, and Brocade all publish lifecycle dates through different channels, use different names for the same milestones, and follow different timelines — which is why missing the distinction can leave your data centre running unsupported hardware or software without realising it.

End of Life (EOL) — No Longer Sold

EOL is the date your vendor stops manufacturing and selling a product. After the EOL date, you can no longer buy new units from the OEM — but your vendor still supports the product you already own. Security patches, firmware updates, and maintenance contract renewals are still available for a defined post-EOL window. EOL is the least urgent of the three milestones; your vendor still has your back, just not on new purchases.

End of Support / End of Sale (EOS / EOA) — Support Winding Down

End of Support (EOS) — also called End of Availability (EOA) or End of Engineering Support — is when your vendor stops offering new support contract renewals and stops developing new features. If your existing support contract expires after the EOS date, you cannot renew it with the OEM. The product still functions, but your ability to extend official vendor support is gone. This milestone typically sits between EOL and the final EOSL date.

End of Service Life (EOSL) — All OEM Support Ends

EOSL — also called Last Date of Support (LDOS), End of Support Life, or End of Hardware Maintenance — is the date your vendor stops everything. No security patches. No firmware updates. No spare parts. No support calls. No contract renewals. After the EOSL date, if something breaks or a new CVE is published for that product, the OEM will not fix it. This is the date your entire IT lifecycle plan should be built around.

• Technical support and helpdesk access — ends
• Security patches, vulnerability fixes, and firmware updates — ends
• Software bug fixes and maintenance releases — ends
• Hardware repair services and replacement parts via OEM — ends
• Maintenance and support contract renewals — ends
• End of software maintenance (EOSM) and end of security support (EOSS) — both included

Why EOSL Goes by Many Names — LDOS, EOS, EOSL, Last Date of Support

Every vendor uses different terminology for the same milestone, which is why tracking it across vendors is so frustrating. Cisco publishes a Last Date of Support (LDOS) and an End of Support (EOS) date. HPE and Dell EMC use End of Service Life (EOSL). IBM labels it Last Date of Support (LDOS). Juniper Networks and Brocade write it as End of Support Life (EoSL). NetApp and Pure Storage use End of Availability and End of Engineering Support. Different labels, same meaning: the final date after which the OEM provides zero support for that product.

The Full IT Product Lifecycle Stages

Every enterprise hardware and software product follows a defined lifecycle from launch to end of service life. Here is the order:

1. General Availability (GA) — product launches, fully sold and supported
2. End of New Features / End of Development — no new capabilities, maintenance mode only
3. End of Sale / End of Availability (EOS/EOA) — removed from active sales catalogue
4. End of Life (EOL) — manufacturing stops, product discontinued by OEM
5. End of Software Maintenance (EOSM) — no more patches or bug fixes
6. End of Security Support (EOSS) — no more security patches or vulnerability remediation
7. End of Service Life (EOSL) / Last Date of Support (LDOS) — all OEM support, contracts, and repair services cease

Which Comes First: EOL, EOS, or EOSL?

EOL always comes before EOSL. EOL means no longer sold — your vendor still supports you. EOSL means no longer supported — you are on your own with the OEM. The order is: End of Sale → EOL → EOS → EOSL. The gap between EOL and EOSL varies widely by vendor: Cisco typically gives you 3–5 years between EOL and LDOS; HPE and Dell EMC can range from 18 months to 5 years depending on the product family.

That fragmentation across vendors is exactly why I built EOSL.date — a free, open-source tracker where you can look up EOL and EOSL dates for enterprise hardware and software in one place, without hunting through a dozen vendor portals.

When your hardware or software hits its EOSL date, your vendor's obligations to you end completely. Here is what that means in practice — and what you should do about it.

What is an EOL / EOSL Notice and What Should You Do?

An EOL notice or EOSL announcement is a formal bulletin from your vendor declaring that a specific product model is entering end-of-life or end-of-service-life status. It lists the product name and affected model numbers, the end-of-sale date, the end of software maintenance date, the end of security support date, and the final EOSL date. When you receive one, pull your full asset inventory and find every instance of that model. Then assess whether each device is critical or non-critical, get pricing from at least one third-party maintenance (TPM) provider, and set a firm decision deadline — ideally 12–18 months before the EOSL date, not 90 days.

Security and Compliance Risks of Running EOSL Hardware or Software

After your EOSL date, any new CVE (Common Vulnerability and Exposure) discovered for that product will never be patched by the OEM. Your infrastructure becomes a permanent, known attack surface. For organisations running PCI-DSS, HIPAA, ISO 27001, SOC 2, NIST, or FedRAMP audits, this is a direct finding — auditors expect every component to be within a vendor support window. Running EOSL hardware or end-of-life software in a regulated environment is not just a technical risk; it is a compliance failure waiting to be documented.

Operational Risks — Parts, Firmware, and Support SLAs

On the hardware side, EOSL means no spare parts through OEM channels, no firmware fixes for hardware defects, and no support SLA if a disk fails, a storage controller crashes, or a SAN switch port dies. For tier-1 storage arrays or core network fabric, your mean time to repair (MTTR) goes from hours — with an OEM-backed SLA — to days or weeks waiting on a third-party spare to arrive. The longer a product has been past its EOSL date, the harder and more expensive spare parts become to source.

Your Options — Upgrade, Replace, or Third-Party Maintenance (TPM)

When EOSL is approaching, you have three paths:

• Upgrade or replace — migrate to a current-generation, supported platform. The cleanest option long-term, but it requires capital budget, migration planning, and validated testing before cutover.
• Third-party maintenance (TPM) — engage a TPM provider to cover hardware support, spare parts, and on-site engineers for your EOSL equipment. TPM typically costs 50–80% less than OEM contract renewals and can extend the operational life of EOSL hardware by 3–7 years, buying you time for a planned migration instead of an emergency one.
• Time and material (T&M) — both OEMs (on a best-effort, no-SLA basis) and TPM providers offer T&M per-incident pricing where you pay for engineer time and parts only when something breaks, with no annual contract commitment. T&M suits low-criticality EOSL equipment where failures are infrequent, though OEM T&M availability shrinks the older the product gets.
• Self-maintenance — use internal staff and a pre-built spare parts inventory. Viable for non-critical, low-complexity systems. Not recommended for production storage arrays, SAN directors, or core routing platforms where a failure means immediate business impact.

EOSL applies to both hardware and software — but what you need to do about it is different for each. A software EOL date and a hardware EOSL date carry different risks, different timelines, and different remediation paths.

How Software EOL Works — Operating Systems, Runtimes, and Applications

For software, EOL means no more patches. Windows 10 reached end of life in October 2025 — after that date, any new security vulnerability in Windows 10 will not be fixed by Microsoft. Python 2.7 hit EOL in January 2020. Every major RHEL version has a defined end-of-support date. Node.js, PHP, Ruby, Java LTS releases, and .NET Framework versions each publish their own EOL schedule. If you are running any of these after their EOL date, you are accepting known, unpatched CVEs in your infrastructure stack with no fix path from the vendor.

How Hardware EOSL Works — Servers, Storage, and Networking

For hardware, EOSL means physical replacement — you cannot patch a storage controller the way you can an OS. When HPE ProLiant Gen9 servers, Dell EMC VMAX storage, Cisco UCS M4 blade servers, NetApp FAS8000, or Brocade DCX directors hit their EOSL date, you need a physical migration plan. Hardware EOSL on a major platform generation often hits multiple devices across your data centre simultaneously, which is why tracking server end of life, storage array EOSL, and network switch end of support dates well in advance matters so much for planning your refresh cycle.

What About Smartphones and Consumer Devices?

The same lifecycle applies to consumer technology. Android devices, Samsung Galaxy models, and iPhones all have defined end-of-support dates — after which they stop receiving security patches. A phone running an unsupported Android version has known, unpatched vulnerabilities and no fix coming from the manufacturer. I built EOSL.date to cover enterprise infrastructure — servers, storage, networking, and enterprise software — but the concept and the risk are identical whether the device is a rack server or a smartphone.

Why the Risk Profile Differs Between Hardware and Software EOSL

Software EOSL risk is primarily a security and compliance problem — an unsupported OS can sometimes be partially mitigated with network isolation, WAFs, or virtual patching while you plan a migration. Hardware EOSL risk is more immediate: a failed storage controller or SAN switch after EOSL means no OEM repair, potentially no available spare part, and direct, unplanned downtime. Hardware EOSL also demands earlier action — procurement cycles, hardware delivery lead times, and data migration complexity mean you need 12–18 months of runway, not 60 days.