Developers Criticized Microsoft's Three-Year LTS Support Window for .NET Platform

A developer has reignited a long-standing dispute over Microsoft's .NET platform support policy by opening a new GitHub issue arguing that the three-year long-term support window is too short for enterprise system update cycles.

How the current .NET support model works

Microsoft's current scheme divides .NET releases into two types based on support duration, and this scheme itself has become the subject of complaint:

• Even-numbered .NET versions receive three years of free long-term support (LTS)
• Odd-numbered versions are considered standard releases (STS) and are supported for only 18 months
• The developer believes the three-year window for LTS versions is insufficient for large enterprises
• The dispute is not new — complaints about this policy are being raised again, now through a new GitHub issue, not for the first time

Why enterprises are dissatisfied with the update cycle

Large organizations typically go through internal cycles of testing, coordination, and gradual rollout of new platform versions across their entire infrastructure — from individual services to legacy systems on which the business depends — and these cycles rarely fit within three years. When the support window ends before a company can complete the transition to a new LTS version, IT departments are forced either to accelerate migration at the expense of testing quality, or to remain on a version without official support and security patches, creating risk for the entire infrastructure.

This very gap between Microsoft's release pace and the actual speed of enterprise system updates prompted the new GitHub appeal. The issue's author notes that similar complaints from the enterprise software development community have been heard for years, but the platform's support model has not fundamentally changed.

What changes are being proposed

Although there are no specific counter-proposals from Microsoft following the complaint, the fact of renewed discussion in a public GitHub issue shows that the current asymmetrical support model — three years for even versions and 18 months for odd ones — remains a source of friction between the platform's development pace and its implementation practice in large organizations.

How this differs from other platforms

The asymmetrical support scheme — a short cycle for some versions and a long one for others — is not unique to .NET, but at Microsoft it regularly triggers complaints from developers who maintain large enterprise systems. Companies whose migration between major versions requires coordination with dozens of internal teams, integration testing, and gradual production rollout often cannot physically meet the three-year window, even if they start preparation early.

For such organizations, the difference between 18 months and three years of support is not a technical detail but a budget question: extending support for an outdated version manually or emergency migration costs more than a planned transition.

What could solve the problem

The developer who raised the issue in a new GitHub post argues his position based on large organizations' update cycles, not the convenience of individual developers. Possible solutions discussed in similar disputes around LTS policies for software platforms typically 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 typical procurement and budgeting cycles in large companies. Which of these options Microsoft will consider is not clear from public materials, and the company's response to the specific issue has not yet been reported.

What this means

The dispute over .NET LTS support timelines is not a one-off complaint but a recurring theme in the enterprise software development community. As long as Microsoft maintains the model of "three years for even versions, 18 months for odd ones," companies with long update cycles will have to factor the risk of outdated support into their migration plans — or continue pushing for a policy review through public channels like GitHub.