The GitHub Issue That Restarted the Debate
Earlier this month, a developer opened an issue on the official .NET GitHub repository and basically said what half the enterprise .NET community has been thinking for years: Microsoft's long-term support window is too short for real upgrade and adoption cycles. The complaint isn't new — a nearly identical thread ran in 2023 — but it's getting louder, and the timing matters more than ever.
Here's why this keeps resurfacing. Microsoft ships a new major .NET release every year. Even-numbered versions get three years of free LTS support. Odd-numbered ones? Two years of short-term support before they're EOL. The math is brutal: by the time .NET 11 drops, two of those three years for .NET 10 are already gone. You've got roughly one year to plan the upgrade, test it against your entire dependency tree, and actually deploy it across production workloads. One year.
And that's before you factor in the human side of things — stakeholders who look at a software release with twelve months until EOL and decide it's not worth adopting. I've seen it happen. It's embarrassing to admit, but enterprises will literally delay purchasing or deploying software because the clock is already ticking down.
How .NET's Lifecycle Actually Works
Let me walk through the mechanics, because this is where the confusion lives. Modern .NET — formerly known as .NET Core before Microsoft rebranded it back to just ".NET" in 2020 — follows an annual cadence. Every November, a new major version lands.
Even-numbered releases are LTS: three years of free support, including security patches and bug fixes. Odd-numbered releases get STS — two years of maintenance before they're retired. Simple on paper.
Then there's the legacy .NET Framework, the Windows-only version that's been in maintenance mode for years. It's supported for roughly a decade, tied to the Windows OS lifecycle. Breaking changes are rare — which is both its strength and its curse. The problem? It's old. A lot of modern libraries, including Microsoft's own ASP.NET Core, don't support it anymore. You're stuck choosing between a supported but aging platform and an unsupported but modern one.
The official support policy is documented at dotnet.microsoft.com, and if you read it carefully, the asymmetry jumps out: three years of free LTS support for modern .NET versus a decade-plus for the legacy framework. The gap isn't just wide — it's structurally incentivizing enterprises to stay on the thing that's falling out of ecosystem support.
The One-Year Upgrade Window
This is the core pain point, and it's where a cloud security incident response playbook starts to matter more than most people realize. When your runtime environment is EOL, you're running unpatched code. That's not a development inconvenience — it's a security exposure.
One developer cited telemetry showing roughly 50 percent of their deployed software is running EOL versions. Half. That's not a edge case; that's the norm for many enterprises with large .NET footprints. Another commenter put it plainly: "I try to use netfx as much as I can because of the ten-year support tied to OS life, but that's getting harder and harder as the ecosystem drops FX support."
The hesitation is rational. Customers don't want to adopt software that's approaching its EOL window. It creates a perverse dynamic where the safest choice from a security standpoint — staying on an older, supported version — is actively discouraged by ecosystem decay. Libraries stop supporting .NET Framework. NuGet packages drop compatibility. You're trapped between a rock and a hard place, and the clock keeps ticking.
How .NET Compares to Java and Python
Let's put this in perspective against platforms that enterprises actually trust with their security-critical workloads.
Java offers five years of support for LTS versions, plus extended commercial support options that push it even further. Python provides five years of security fixes for every release, regardless of whether it's LTS or not. Microsoft's free .NET support period? Three years for LTS, two for STS.
The gap isn't marginal. Java and Python give enterprises roughly 60-100 percent more time to plan, test, and deploy upgrades. For teams managing 365-day-a-year security operations, that extra time translates directly into fewer rushed migrations and fewer vulnerabilities sitting in unpatched runtime environments.
I'll be honest: when I'm reviewing a vendor's platform maturity for a security & compliance center, the support lifecycle is one of the first things I flag. A three-year window for a runtime that underpins mission-critical applications doesn't pass the smell test. Not because Microsoft is negligent — they're shipping code fast, and innovation matters — but because the support model assumes an upgrade cadence that most enterprises simply can't sustain.
The Real Cost of Upgrading
Upgrading .NET isn't like flipping a switch. Breaking changes between major versions can be substantial. Third-party dependencies may not have updated packages yet. Your testing cycle alone can eat months. And then there's the human cost — sometimes you need to pay external developers just to navigate the migration.
A comment from the 2023 issue captured this perfectly: "The .NET Framework only incurs costs for functional modifications and bug fixes, but .NET tries to add to that the non-negligible cost of version upgrades at relatively short intervals."
That's the crux of it. Legacy .NET Framework costs you nothing beyond maintaining existing functionality. Modern .NET adds the overhead of repeated major-version migrations on top of that. For enterprises running thousands of applications, that cost compounds fast.
And here's what keeps me up at night from a security perspective: every day an application runs on an EOL runtime, it's exposed to unpatched vulnerabilities. The shorter the upgrade window, the more likely enterprises are to fall behind. It's not a theoretical risk — it's an operational reality that shows up in audit findings and incident postmortems.
Microsoft's Response and the Paid Support Question
Richard Lander, a program manager on the .NET team, addressed this exact concern back in 2023. His answer was pragmatic: Microsoft chose the support timeframes to "balance stable deployment time for users and enabling the team to spend most of their time innovating."
He also revealed something important: Microsoft had discussed longer support frames and even extended paid support offerings. They opted to continue with only the free support plan instead.
That decision matters. If Microsoft had offered a paid extended-support tier — say, five years for LTS versions at an enterprise license fee — many organizations would've taken it. The budget exists. The need is real. But the option isn't on the table.
In March 2026, Microsoft principal software engineer Shay Rojansky requested feedback on dropping .NET Framework support in the Microsoft.Data.Sqlite library. A commenter responded that ".NET Standard 2.0 and Framework 4.8 are the only .NET targets with reasonable support timelines available for enterprise." Rojansky called the comment off-topic, and the proposal was closed as "not planned."
That closure tells you everything about Microsoft's priorities right now. They're all-in on modern .NET, and they expect the ecosystem to follow — regardless of whether enterprises are ready.
What This Means for Security Operations
Let me connect this to something concrete. If you're building or maintaining a cloud security incident response playbook, your runtime environment is part of that equation. An EOL .NET runtime means unpatched vulnerabilities, compliance gaps, and audit findings that no amount of WAF tuning can fix.
The .NET support policy isn't just a developer concern — it's an infrastructure security issue. Every enterprise running .NET applications needs to treat their runtime upgrade cadence with the same rigor they apply to OS patching or dependency updates. The one-year window Microsoft provides is simply too tight for most organizations to execute properly.
For security & compliance analysts, this creates a specific risk pattern: applications that should be upgraded are stuck on EOL versions because the migration timeline doesn't fit into production schedules. The result is a growing inventory of unpatched runtimes that show up in vulnerability scans and compliance reports. It's a slow-burn exposure, but it's real.
The bottom line: Microsoft's innovation velocity is impressive, but their support model assumes an upgrade discipline that most enterprises can't maintain. Until that changes — whether through longer free support, paid extended lifecycles, or both — enterprises will keep making suboptimal choices between security and pragmatism. And someone's going to pay for it when a zero-day hits an EOL runtime.