How Long Does Software Actually Last? Lifespan Benchmarks by Software Type in 2026

Every CTO has heard the question from a non-technical stakeholder: “How long will this software last?” The honest answer is not the number the engineering team estimates. Instead, it is the number set by the software’s weakest dependency. Additionally, in 2026, that calendar is unusually harsh.

This piece is the third in a maintenance trilogy. Our earlier Software Maintenance Cost Percentage: 2026 Industry Benchmarks put the honest annual cost at 15–25% of build cost. Furthermore, The True Cost of Deferred Software Maintenance walked through what happens when teams skip that spending. This one answers the follow-up: how long does software last before continuing to maintain it becomes the wrong decision?

Why “lifespan” is usually the wrong question

Software lifespan is often quoted as a single number — five years for SaaS, three for mobile apps, a decade for enterprise line-of-business systems. However, those numbers rarely survive contact with the realities of production. Instead, effective lifespan is set by whichever underlying dependency ages out first.

For a typical business application, the candidates are the runtime (PHP, Node.js, Python), the framework (Laravel, Django, Rails, Angular), the cloud services it consumes, the mobile app store target SDK requirements, and the regulatory frameworks it must comply with. Consequently, the correct question is not “how long does this software last?” but “which of my dependencies fails first, and when?”

The remainder of this article works that question backward from the actual 2026-2028 calendar.

The 2026-2028 EOL calendar you should already have on your wall

The most defensible statement we can make about software lifespan in 2026 is that the vendors themselves already publish these dates. Additionally, they are non-negotiable.

PHP (source: php.net/supported-versions.php, verified 2026-07-06):

Node.js (source: nodejs/Release GitHub, verified 2026-07-06):

Laravel (source: laravel.com/docs, verified 2026-07-06):

Notably, we intentionally omit Laravel 12 support dates from this table. The specific dates commonly quoted for L12 did not pass our verification. Additionally, we would prefer to leave the row blank rather than publish a potentially incorrect number.

For any application built on PHP 8.1, PHP 8.2 by the end of 2026, Node.js 20, or Laravel 11, the security-patch clock is either already stopped or ticking to zero inside the article’s publication window.

Framework EOL is the dominant trigger for lifespan.

Runtimes and frameworks are not the only drivers of lifespan, but in our operational experience, they are the most common. Additionally, the pattern is remarkably consistent: teams do not decide when to rewrite. Their dependencies decide for them.

A concrete 2026 case study makes the point. HashiCorp deprecated and archived the Cloud Development Kit for Terraform (CDKTF) on December 10, 2025, citing “lack of product-market fit at scale.” Consequently, every production team that had adopted CDKTF as its infrastructure-as-code layer faced a forced decision within twelve months. The choices were migration to the community fork CDK Terrain, rewrite to HCL, port to Pulumi or AWS CDK, or accept an unmaintained dependency in a security-critical layer. Notably, this was not a slow deprecation over several years. It was a single vendor announcement that reset the lifespan clock for hundreds of engineering teams.

Furthermore, this pattern repeats every year. ThoughtWorks Technology Radar Volume 34 (April 2026) catalogs several parallel shifts. Meanwhile, mobile app teams face their own version through Google Play’s rolling minimum target SDK enforcement and Apple’s roughly four-year iOS SDK support window.

The takeaway is straightforward. Effective lifespan is not a function of code quality or architectural discipline. Instead, it depends on which of your dependencies is deprecated first.

Regulatory compression events are accelerating rewrites.

Two regulatory shifts in 2026 compress software lifespans by hard-coding new obligations into existing systems.

The EU AI Act. Full applicability began on August 2, 2026 (source: European Commission’s digital strategy portal). Additionally, the GPAI model obligations already became applicable on August 2, 2025, and Article 50 transparency rules take effect in August 2026. Fines can reach €15M or 3% of worldwide annual turnover. Furthermore, any system that touches AI-generated content, general-purpose AI models, or automated decision-making for European users is now inside scope. Some carve-outs and grace periods apply. For example, high-risk AI in already-regulated products is extended to August 2, 2028, and certain Annex III systems are extended to December 2, 2027, under the AI Omnibus political agreement. However, the majority of the compliance surface is already live.

PCI DSS v4. x. The Payment Card Industry Security Standards Council introduced 64 new requirements in v4.0. Additionally, 51 of those became mandatory on March 31, 2025 (source: PCI Security Standards Council blog). Consequently, any e-commerce, fintech, or payment-adjacent system still running the v3.2.1 architecture as of July 2026 is out of compliance. Furthermore, the v4.0.1 limited revision from June 2024 explicitly did not push this date.

These are not the only compression events. Meanwhile, WCAG accessibility mandates, ASEAN cross-border data transfer frameworks, and jurisdiction-specific rules (Singapore MTCS, Philippines DPA amendments, and Cambodia digital ID requirements) each shorten the effective lifespans of specific applications. However, the two above have the largest cross-industry blast radius in 2026.

Effective lifespan by software type

With the EOL and regulatory picture in mind, here are practical, effective lifespan ranges by software type. Additionally, these reflect Pegotec’s operational experience — not verified median-years data from primary analyst research, which we could not confidently surface during our July 2026 verification pass.

For each category, the number range is heavily conditional on the runtime and framework choice. Notably, a Laravel-based SaaS resets its lifespan clock every two years when a new major Laravel version is released. Meanwhile, a well-maintained industrial platform on a stable Java LTS can quietly run for a decade without a rewrite.

The honest takeaway is that lifespan-by-type ranges are directional. However, the runtime and framework EOL calendar is not.

How to calculate your own lifespan clock

The rubric we use in Pegotec engagements takes five inputs.

First, list every runtime and framework dependency your application relies on. Additionally, note the current major version.

Second, look up the security-support end date for each. Publicly-maintained aggregators like end-of-life dates are useful. However, cross-check against the vendor’s own published policy.

Third, take the earliest of those dates. That is the outer bound on your current-stack lifespan.

Fourth, layer on the regulatory calendar for your industry. Specifically, EU AI Act enforcement dates, PCI DSS mandatory requirements, and jurisdiction-specific mandates all shorten the outer bound.

Fifth, subtract at least six months from the outer bound. That is your effective planning deadline. Additionally, six months is the minimum lead time we see for a disciplined targeted rewrite. Consequently, “we still have another year” is often not what teams actually have.

For a Laravel 11 application deployed in early 2025, the security patch clock stopped on March 12, 2026. Furthermore, the effective planning deadline was six months earlier — September 2025. Teams that started the Laravel 13 migration in autumn 2025 are landing safely in mid-2026. Meanwhile, teams that delayed past March 2026 are running unpatched security-support code today.

What “healthy” versus “alarming” software age looks like

Not every application on an older version is a crisis. Additionally, healthy engineering teams often maintain one major version behind the current one on non-critical systems.

A healthy lifespan profile looks like this: every runtime and framework in the estate is either on active support or within 12 months of security support end, with a planned migration. Additionally, a documented rewrite-vs-refresh decision framework exists. Furthermore, regulatory mandates for the relevant jurisdictions are mapped against the calendar.

An alarming profile looks like this: one or more runtimes are past the security support end. No migration plan is scheduled. Nobody on the team can name the next EOL date for the primary framework. Meanwhile, regulatory obligations are handled reactively.

Between healthy and alarming sits a caution band. Specifically, the primary stack is fine, but a secondary integration (a payment library, an infrastructure-as-code tool, a mobile SDK) is drifting. Notably, most rewrites we get called in for start as caution-band problems that were left unattended for eighteen months.

Refresh in place, targeted rewrite, or full rewrite

Three paths address a lifespan cliff. Additionally, most real remediations use a combination.

Refresh in place. Upgrade the runtime and framework major versions while preserving the application architecture. Furthermore, this is the correct choice for most applications with a sound underlying design. For a Laravel 11 → 13 migration in a well-tested codebase, the effort is typically 2 to 8 engineer-weeks, depending on the custom middleware surface area.

Targeted rewrite. Rewrite the specific subsystem responsible for the lifespan cliff — legacy authentication, a payment integration, an obsolete data pipeline — while continuing to maintain the rest.

Full rewrite. Rebuild from scratch on a modern stack. Notably, this is the least common correct answer. Additionally, we deliberately avoid repeating the popular “rewrites cost 4× to 10× the original build” folklore in this article because we could not find its primary source during verification. However, the operational reality is that rewrites frequently overrun their deadlines. Consequently, the decision should be reserved for cases where refresh-in-place and targeted-rewrite genuinely will not close the gap.

For most operational teams, the pattern that works is refresh-in-place for 70% of the estate, targeted rewrite for 20%, and full rewrite for 10% at most. Additionally, Managing Technical Debt: A Practical Guide for CTOs covers the operating cadence.

How Pegotec helps

Pegotec runs runtime-lifecycle audits as a discrete engagement. Specifically, the output is an EOL-mapped inventory of all runtimes, frameworks, integration libraries, and cloud services in the estate. Additionally, it includes a categorized remediation plan and a twelve-month migration calendar sized against your actual engineering capacity. Furthermore, we operate the migration as a managed engagement for teams that would rather buy the discipline than build it in-house.

Our own delivery discipline uses the same tools. Consequently, the numbers and dates in this article reflect the calendar we work against every planning cycle.

Read next

If you found this useful, read next:

• Software Maintenance Cost Percentage: 2026 Industry Benchmarks — how much should we spend on maintenance?
• The True Cost of Deferred Software Maintenance: 2026 Failure Benchmarks — what happens when we don’t spend it?
• Managing Technical Debt: A Practical Guide for CTOs — the operating cadence for a healthy estate

Frequently Asked Questions