End of life (EOL) is the point in the software lifecycle after which a vendor or project stops providing updates, security patches and support for a product or a specific version. The software usually keeps running after that date, but every newly discovered defect or vulnerability remains unfixed, so the risk of using it grows with each month.
In software maintenance, end of life is the final milestone of a published support policy. It follows earlier stages such as general availability, maintenance and deprecation, and it is the date that drives upgrade planning, budget decisions and compliance reviews.
How end of life fits into the software lifecycle
End of life marks the last stage of a version’s supported life, reached after a sequence of announced phases. Most vendors publish these phases in advance, often years ahead, so that customers can plan migrations instead of reacting to a sudden withdrawal.
The vocabulary differs between vendors, which causes confusion. Some separate end of sale (the product can no longer be bought), end of mainstream support (no new features or non-security fixes) and end of extended support (no security fixes at all). In most usage, end of life refers to the final point, when no further fixes of any kind are released. The table below shows a typical sequence.
| Phase | What the vendor still provides | What changes for users |
|---|---|---|
| General availability | Features, bug fixes, security fixes | Recommended for new deployments |
| Maintenance or mainstream support | Bug fixes and security fixes | No major new features |
| Deprecation announcement | Fixes continue, removal date is published | Migration planning should begin |
| Extended or security-only support | Critical security fixes only | Often paid or limited in scope |
| End of life | Nothing | Every new vulnerability stays open |
Support windows and typical durations
The length of a support window depends on the release model of the product. Projects with frequent releases support each version only briefly, while long-term support (LTS) releases are designed to stay supported for several years so that stable environments can avoid constant upgrades.
| Release model | Typical support length | Where it is common |
|---|---|---|
| Rolling or short-cycle release | Weeks to a few months | Browsers, developer tools |
| Regular feature release | About 6 to 18 months | Language runtimes, frameworks |
| LTS release | About 2 to 5 years | Linux distributions, runtimes, databases |
| Enterprise product with extended support | About 7 to 10 years or more | Operating systems, commercial databases |
These ranges are typical, not fixed. The actual date is always the one in the vendor’s published policy, and some vendors attach end of life to a calendar date while others tie it to a later release, for example a fixed number of months after the next major version appears.
End of life compared with related lifecycle terms
End of life is often confused with deprecation, end of sale and end of support, yet each describes a different commitment. Getting the distinction right matters, because contracts, audits and security policies refer to specific terms.
| Term | Meaning | Does the software still receive fixes |
|---|---|---|
| Deprecation | Feature or version is discouraged and scheduled for removal | Yes, for now |
| End of sale | Product or license can no longer be purchased | Usually yes |
| End of mainstream support | No new features or non-security fixes | Security fixes only |
| End of life | Vendor support ends completely | No |
| Abandonware | Product is unsupported without any formal announcement | No |
Semantic versioning helps here, because a new major version number signals breaking changes and often starts the countdown for the previous major line. A release candidate, by contrast, belongs to the start of the lifecycle and has no end-of-life date of its own.
Managing software that reaches end of life
Managing end of life means keeping an inventory of versions and their EOL dates and starting migration well before the date arrives. Mature IT teams usually begin planning 12 to 24 months ahead for major platforms, because testing, procurement and staff time take longer than the upgrade itself.
| Option | When it fits | Main risk |
|---|---|---|
| Upgrade to a supported version | Compatible successor exists | Regressions and retesting effort |
| Migrate to another product | Successor is unsuitable or too costly | Data migration and retraining |
| Buy extended support | Migration needs more time | Rising cost, limited fixes |
| Isolate and accept the risk | Legacy system cannot change, for example lab equipment | Residual exposure, audit findings |
Isolation is a compensating control, not a fix. It typically combines network segmentation, removal of internet access, strict accounts and monitoring, and it should be documented with an owner and a review date.
Risks and common mistakes
The main risk of running end-of-life software is accumulating unpatched vulnerabilities, which attackers actively look for because the fixes in newer versions reveal exactly what is broken in the old ones. Several further mistakes are common in practice.
- Tracking only applications: runtimes, libraries, firmware and container base images also reach end of life and are often forgotten.
- Confusing end of sale with end of life: a product that can no longer be bought may still be fully supported for years.
- Ignoring dependencies: a supported application may run on an end-of-life runtime or database, which inherits the risk.
- Late compliance discovery: many security standards and cyber insurance policies treat unsupported software as a finding.
- Assuming it still works safely: functional stability says nothing about security exposure.
The simple explanation
End of life is the date when the maker stops looking after a piece of software. It does not switch off on that day. It keeps working, but nobody repairs it anymore.
Think of a car model whose manufacturer stops making spare parts and recall fixes. You can still drive it, but if a dangerous fault is found, no repair will come. With software, those faults are often security holes, so staying on an end-of-life version becomes riskier every month.
How it is used in practice
A regional hospital runs its appointment system on a database version whose vendor announces end of life in 18 months. The IT team records the date in its asset inventory, and the risk register flags it as a priority item.
Over the next year, the team builds a test environment on the supported version, finds two incompatible stored procedures, fixes them and trains staff. The migration takes place on a weekend, four months before the deadline, with a tested rollback plan.
A connected laboratory analyzer, however, can run only on an operating system that has already passed end of life. The team moves it to an isolated network segment with no internet access and documents the exception. As a result, the hospital passes its next security audit with no unsupported software in general use and one formally accepted, controlled exception.