Developers push back on Microsoft's three-year LTS window for .NET

A developer has reopened a long-running debate over Microsoft's support policy for .NET. In a new GitHub issue, they argue that the platform's three-year long-term support window is too short for enterprise upgrade cycles.

How the current .NET support model works

Microsoft's current model splits .NET releases into two tiers based on how long they're supported, and that model is the target of the complaint:

• even-numbered .NET versions get three years of free long-term support (LTS)
• odd-numbered versions are standard-term support (STS) releases and are supported for just 18 months
• the developer considers the three-year window for LTS versions insufficient for large enterprises
• the debate isn't new: this complaint about the policy has been raised before, and is now resurfacing in a new GitHub issue rather than appearing for the first time

Why enterprises are unhappy with the upgrade cycle

Large organizations typically run new platform versions through internal cycles of testing, sign-off, and gradual rollout across their entire infrastructure, from individual services to business-critical legacy systems. Those cycles rarely fit into three years. When support ends before a company has finished moving to the next LTS version, IT departments face two bad options: rush the migration and cut corners on testing, or stay on a version that no longer gets official support or security patches, which puts the whole infrastructure at risk.

That gap between Microsoft's release cadence and the actual pace of enterprise upgrades prompted the new GitHub issue. Its author notes that developers of enterprise software have been raising similar complaints for years, yet the platform's support model hasn't fundamentally changed.

What developers want changed

Microsoft hasn't yet offered any concrete counterproposals in response to the complaint. Still, the fact that the discussion has flared up again in a public GitHub issue shows that the current asymmetric support model — three years for even-numbered versions and a year and a half for odd-numbered ones — remains a source of friction between how fast the platform evolves and how large organizations actually adopt it.

How this compares with other platforms

Asymmetric support schemes, with a short cycle for some versions and a long one for others, aren't unique to .NET. But Microsoft's version of the model regularly draws criticism from developers who maintain large enterprise systems. Companies where moving between major versions means coordinating with dozens of internal teams, testing integrations, and gradually rolling changes out to production often simply can't fit into a three-year window, even when they start preparing early.

For these organizations, the difference between 18 months and three years of support isn't a technical detail but a budget issue: keeping an outdated version supported on their own or pushing through an emergency migration costs more than an orderly, planned transition.

What could solve the problem

The developer behind the new issue bases their argument on the upgrade cycles of large organizations, not on convenience for individual developers. In debates like this one over software platform LTS policies, the proposed fixes usually come down to a few options: extend the support window for LTS versions, introduce a separate paid extended-support tier for enterprise customers, or align the release cycle with the typical procurement and budgeting cycles at large companies. Which of these options Microsoft might consider isn't clear from the available information, and no response from the company to this particular issue has been reported so far.

What this means

The dispute over .NET's LTS support window isn't a one-off complaint but a recurring theme among enterprise software developers. As long as Microsoft sticks with its "three years for even-numbered versions, 18 months for odd-numbered ones" model, companies with long upgrade cycles will have to factor the risk of lapsed support into their migration plans — or keep pushing for a policy change through public channels like GitHub.