DEVCLASS

A developer has reopened a long-standing complaint on GitHub arguing that .NET's three-year LTS support window is insufficient for enterprise adoption cycles. The core issue is that by the time the next LTS version ships, only one year remains before the current LTS reaches end-of-life, leaving little time for upgrades. This is driving some developers to stick with the aging .NET Framework, which benefits from Windows OS-tied support timelines of roughly ten years. Microsoft has previously acknowledged the concern but opted to maintain its current free support policy, which is shorter than comparable platforms like Java (5+ years) and Python (5 years). The situation is worsening as the ecosystem increasingly drops .NET Framework support, squeezing enterprise developers from both sides.

.NET's long-term support is not long-term enough, dev complains

Sure, but modern .NET upgrades are not as painful as Framework. The initial jump to modern .NET was challenging, but the incremental upgrades after are fairly trivial.
IMO, the bigger issue are the constant NuGet security updates. The larger the project (more packages) the more of a pain point it becomes.

upport policies can influence adoption just as much as new features.

I think the issue is not only the short LTS period itself, but the total cost of platform transition.
Frequent .NET releases are good news in one sense: the ecosystem is active, Microsoft keeps investing, and developers get better performance, tooling, and modern platform options.
But in long-lived business systems, the stressful part is that backward compatibility, migration paths, documentation, and tooling maturity do not always keep up with that speed.
So the burden is not just “upgrading every few years.”
It is also the continuous stress of learning new platform choices and deciding whether the new stack is stable enough for real projects.

For me switching from .NET Framework to the new .NET meant a lot of „oh, and I still have to upgrade that“… if you have a lot of small pieces, utilities, services you constantly come accross one that is still on the old version. Unless you mercilessly automate upgrading, combined with rigorous testing, having components that are more than 3 years old since the last time someone had to change something is fairly easy…