How Long Does Software Actually Live? We Measured 7,144 Versions to Find Out
Every piece of software you deploy is on a clock. The vendor set it the day the version shipped, and when it runs out, the security patches stop. But how long is that clock, typically? Vendors publish lifecycles one product at a time; nobody had put a number on software as a whole. So we did. We measured the release-to-end-of-life span of 7,144 versions across 463 products in endoflife.ai's own lifecycle database — the same data our tracking tools run on.
Eighteen months matters because it is shorter than most organizations' upgrade cycles. If your team revisits its stack every two or three years — a perfectly normal cadence — then the median version you deploy will spend part of its production life unsupported. Not because anyone was negligent. Simply because the software's clock is shorter than your calendar. This is the mechanism by which end-of-life software accumulates silently in every environment: version by version, each one outliving its own support window before anyone gets around to touching it.
Support Lifespans by Category
The overall median hides enormous variation. Here is what we found when we grouped the 7,144 measured lifespans by product category:
| Category | Version lifespans measured | Median lifespan (years) | Mean lifespan (years) |
|---|---|---|---|
| Hardware | 100 | 2.9 | 2.5 |
| Operating systems | 370 | 1.6 | 2.9 |
| Databases | 228 | 1.6 | 2.5 |
| Security products | 61 | 1.3 | 2.3 |
| Frameworks | 195 | 1.1 | 1.5 |
| Runtimes | 221 | 1.0 | 1.8 |
| Cloud services | 142 | 0.9 | 1.0 |
Three patterns jump out of this table, and each one has a practical consequence.
Cloud services die fastest — the cloud doesn't wait for you
Cloud service versions have the shortest median lifespan of any category: 0.9 years. And notice the mean is barely higher, at 1.0 — there is no long tail of generously supported cloud versions pulling the average up. The distribution is uniformly short. When a managed database engine version or a cloud platform release is deprecated, the provider retires it on their schedule, not yours; there is no air-gapped server you can quietly keep running. Of all the categories we measured, this is the one where "we'll get to it next quarter" most often means "we missed the window."
Runtimes and frameworks turn over roughly yearly — the dependency treadmill
Runtimes show a median lifespan of 1.0 years; frameworks, 1.1. This is the treadmill every development team lives on: the language version under your application and the framework on top of it each expect to be replaced about once a year. An application built and left alone for two years is, statistically, running on an unsupported runtime and an unsupported framework — a compounding problem, because upgrading a framework often forces a runtime upgrade, and vice versa. The longer you wait, the more rungs of the ladder you have to climb at once.
Hardware and enterprise servers live 10+ years — and that's a trap of its own
Hardware has the longest category median at 2.9 years, and the longest-lived individual products in the entire dataset are hardware and enterprise server platforms. The top ten products by median version lifespan:
| Product | Median version lifespan (years) |
|---|---|
| Internet Explorer | 17.0 |
| Atlassian Data Center | 12.2 |
| Raspberry Pi | 11.7 |
| Apache HTTP Server | 11.6 |
| NVIDIA GPU | 11.5 |
| Windows PowerShell | 10.5 |
| SNS hardware | 10.4 |
| SharePoint | 10.3 |
| Azure DevOps Server | 10.1 |
| Microsoft Exchange | 10.1 |
Internet Explorer versions were supported for a median of 17.0 years — the longest in our dataset, and a reminder that longevity is not the same as health. The rest of the list is dominated by the platforms enterprises anchor entire architectures on: SharePoint, Exchange, Azure DevOps Server, Atlassian Data Center. A decade of support feels like permanence, so organizations build on these products as if they were load-bearing walls. Then the decade ends — all at once, for everything built on top — and the migration is measured in years, not sprints. Long lifecycles don't prevent stranding; they defer it and concentrate it.
Why the Average Lies: Mean vs. Median
Look back at the category table and compare the operating system row: median 1.6 years, mean 2.9. Databases show the same shape — median 1.6, mean 2.5. When a mean sits that far above its median, a small number of very large values are dragging it upward. In this data, those values are the long-LTS products: enterprise operating systems with RHEL-style 10-year lifecycles, and databases with similarly generous enterprise support windows.
At the far other end of the distribution sit the rapid-release products: Chrome, Firefox, Rust, Prometheus, Neo4j, Quarkus, nvm, Liquibase, Gleam, and Meilisearch all show median version lifespans of roughly 0.1 years — about 5 weeks. For these products, a version is effectively supported only until the next one ships. "End of life" stops being an event you plan for and becomes a continuous condition: if you are not permanently current, you are permanently behind. That model works fine when updates are automatic (as with browsers) and becomes a genuine operational burden when they are not (as with a database or a language toolchain pinned in a build).
What 18 Months Actually Means for Your Environment
Put the pieces together and the picture is stark. The typical version you run gets 1.5 years of patches. Your cloud dependencies get 0.9. Your runtimes get 1.0, your frameworks 1.1. Meanwhile, the products you planned around — the decade-long enterprise platforms — are the exception, not the rule, and even they eventually expire in bulk.
No team holds 463 products' worth of expiry dates in their heads. The dates aren't announced on your schedule, they don't arrive through any single channel, and they don't wait for your next planning cycle. This is not a discipline problem; it is an arithmetic problem. The only workable answer is to make the tracking systematic:
- Inventory what you actually run. The endoflife.ai scanner reads your dependency and infrastructure manifests and maps them against the lifecycle database, so the starting list is real rather than remembered.
- Check anything on demand. The version checker answers the immediate question — is this specific version still supported, and for how much longer?
- Watch for the dates you can't afford to miss. EOL Watch alerts you when a product you depend on approaches its end-of-life date, so the 18-month clock never runs out silently.
- Put the dates where your team plans. Every product page on endoflife.ai offers a calendar (.ics) feed, so lifecycle deadlines land in the same place as everything else you schedule.
- Bridge deliberately when you're stuck. When a migration genuinely can't finish before the deadline, extended support can buy patched time on an EOL version — as a bridge with an end date, not a destination.
Methodology
This study measured the supported lifespan — the span from release date to end-of-life date — of 7,144 individual software versions across 463 products tracked on endoflife.ai, computed from our lifecycle database as of July 2026. The details that matter for interpreting the numbers:
- Inclusion criteria: a version's lifespan is measurable only if it has both a known release date and a firm end-of-life date. Versions with no announced EOL date were excluded — we measured completed or committed lifecycles, not guesses.
- Medians alongside means: we report both throughout because the distribution is heavily skewed. A minority of long-LTS products pull means well above medians (most visibly in operating systems: median 1.6 years, mean 2.9). The median is the honest "typical version" number.
- Category groupings come from endoflife.ai's own product taxonomy.
- Per-version, not per-product-line: these are lifespans of individual versions. A product line can live for decades across many short-lived versions — Debian as a product line spans decades even though each Debian release has a bounded support window. The 1.5-year median describes the version you deploy, not the brand on the box.
The underlying release and end-of-life dates are the same data published on endoflife.ai's individual product pages, where each date can be inspected directly.
Frequently Asked Questions
How long is the average software version supported?
Across the 7,144 versions of 463 products we measured, the median supported lifespan is 1.5 years from release to end of life. The mean is 2.3 years, but it is inflated by a minority of long-LTS products — the median is the better description of the version you typically deploy.
Which software category has the shortest support lifespan?
Cloud services, at a median of 0.9 years across 142 measured lifespans (mean 1.0 — there's no long tail of exceptions). Runtimes (1.0-year median) and frameworks (1.1) are close behind. The extreme cases are rapid-release products like Chrome, Firefox, and Rust, where the median version lifespan is roughly 0.1 years — about 5 weeks.
Which software lives the longest?
By category, hardware: a 2.9-year median across 100 measured lifespans. By product, the longest medians are Internet Explorer (17.0 years), Atlassian Data Center (12.2), Raspberry Pi (11.7), Apache HTTP Server (11.6), and NVIDIA GPU (11.5), with Windows PowerShell, SNS hardware, SharePoint, Azure DevOps Server, and Microsoft Exchange all at or above 10.1 years.
Why does end-of-life software accumulate in organizations?
Because the median version's 1.5 years of support is shorter than most organizations' upgrade cycles. Anything deployed and left alone for about 18 months is statistically likely to be past its end-of-life date — and with 463 products expiring on 463 different schedules, no team can track it from memory. Systematic tracking (inventory, checks, alerts) is the only mechanism that scales.