Enterprise concern: .NET LTS support window too short for upgrade and adoption cycles

[bh-sijtnic]

We are encountering challenges with the current .NET LTS support model when operating large-scale enterprise applications.
This builds on earlier discussions such as #8295, where the 3-year LTS duration and its trade-offs were discussed.
In our case, the combination of LTS duration, release cadence, and overlapping end-of-support dates is creating friction both internally and with external customers.

Context
We maintain a large application (~5 million lines of code) currently on .NET 8 (LTS).
We are nearing completion of upgrading to .NET 10 (LTS), released November 2025. Even with a well-resourced team, this upgrade requires:

• Migration to the VS 2026 toolchain
• Waiting for ecosystem readiness (dependencies, tooling, build systems)
• Extensive regression testing and validation

Completing this upgrade within ~7 months is already considered fast in an enterprise environment.

Issue
The main concern is the effective usability window of LTS releases.

• .NET 8 (LTS) reaches end of support in November 2026
• .NET 9 (STS) also reaches end of support in November 2026

Because of this:

• LTS and STS converge on the same EOL date
• New deployments on .NET 8 are already difficult to justify
• Large customers with vulnerability management requirements are hesitant to adopt a platform that is close to EOL

While we are able to release a new version of our software based on .NET 10, before .NET 8 is officially EOL, this is not good enough for enterprises. We are seeing this directly in recent customer onboarding and procurement discussions. Who are hesitant to adopt software which is soon to run out of the defined EOL window.

Expected behavior
LTS releases are generally expected to provide:

• A stable baseline for multi-year deployments
• Sufficient time for adoption, rollout, and operation
• Clear differentiation from short-term releases

Suggestions
Areas that could help address this:

• Longer LTS support duration
• Extended (possibly paid) support options
• More overlap between LTS releases to increase adoption runway
• Guidance for enterprise deployment and lifecycle planning

We appreciate the improvements in upgradeability and release cadence.
However, in environments with large codebases and strict lifecycle policies, the current LTS timeline and overlap make it difficult to align platform support with real-world adoption cycles.

As it stands, the current LTS cadence is increasingly difficult to align with enterprise-scale development and adoption, and will continue to impact both upgrade feasibility and customer adoption decisions.

[siblznbitz]

Hey @bh-sijtnic - have you checked out Open Rewrite (https://github.com/openrewrite/rewrite)? They've got some helpful tools if this a recurring issue.

I'll link the docs via Moderne (who backs the project) here: https://docs.moderne.io/user-documentation/recipes/recipe-catalog/dotnet/

[ryannewington]

I agree we definitely need longer cycles.

One scenario that doesn't get considered is deployment time of software in enterprises. Not everything written in dotnet is running on a server under the developer's control. Desktop apps in particular. I've got telemetry showing about 50% of the deployed versions of my software out there are running EOL versions. I communicate this with customers but it's one of a thousand things they have to worry about, and it's compounded by the short release cycle.

When .NET 10 came out in November 2025, all my current releases were on .NET 8. At that stage I've got 12 months to migrate all my apps to .NET 10, fix all the dependency issues that come up from third party libs, deal with any deprecations or breaking changes (cert lib changes, binary formatter, etc), retest everything, then publish and let all my enterprise customers know there's a new version they have to install. I'm in this exact cycle right now, only a few months to go before .NET 8 EOL, and I'm still not done. I try and use netfx as much as I can because of the 10 year support tied to OS life, but that's getting harder and harder as the ecosystem drops FX support.

The other scenario worth considering is enterprises that don't have in house devs, who get custom software built by a third party. An org I know of had something written in .NET 6. They tried to upgrade to .NET 8 and couldn't, dependencies needed major rewrites and the skills weren't there in house. So they had to go to tender for dev resources to come fix it. Funding approval, find a vendor, formal procurement. Those processes alone take months, sometimes longer than the tiny 12 month window between one LTS going dead and the replacement being available. That app is still running .NET 6 today.

I get these aren't Microsoft's problems directly. But the people saying "just change the TFM bro, takes two seconds" are almost always speaking from a position where that's actually true for them. Server-side, in house devs, with full control of the deployment target. And that's fantastic for them, genuinely. But the fact that it's frictionless for you isn't evidence the friction doesn't exist for others. All the variables aren't under our control as developers, and enterprises have competing priorities that mean this stuff isn't always at the top of the pile.

There's a longer term angle here too, and this is just a personal take from my experience in the field. The longer this goes on, the more of the deployed dotnet surface area is sitting on EOL runtimes at any given moment, and that fleet only grows as more orgs fall behind. FX had the opposite property - the long OS-tied support meant the installed base stayed patched without anyone having to think about it. Dotnet core trades that for a model that needs active, continuous effort from the orgs least able to provide it. Again, not Microsoft's fault directly, but it's a foreseeable outcome of the cadence. A platform's security reputation gets set by its worst widely deployed installs, not its newest ones. If in 5-10 years a decent chunk of dotnet in the wild is chronically out of support, "dotnet is a security liability" becomes the narrative no matter how good .NET 14 is by then.

Anyway, back to the main point. To summarize, i'd argue it's not directly the 3 year lifecycle that's the problem - it's the 12 month window you get to write, test, validate and deploy EVERYTHING to the next LTS. It's just not long enough in all cases.