The Generous Gift? Microsoft Extends .NET STS Support to 24 Months
Microsoft recently announced a change to their support policy for .NET Standard Term Support (STS) releases. The support period has been extended from 18 to 24 months. At first glance, this appears to be a welcome enhancement, giving developers and organizations more breathing room before forced upgrades. But is this really as generous as it seems?
What’s Actually Changing?
Let’s get the facts straight:
- .NET STS releases (the odd-numbered versions like .NET 9, 11, etc.) will now receive security and quality updates for 24 months instead of 18 months
- This applies retroactively to .NET 9, which will now be supported until November 2026 (instead of May 2026)
- .NET 11, scheduled for release in November 2026, will also receive the extended 24-month support
- Long Term Support (LTS) releases remain at 36 months of support
Why Now? The Reality Check
While Microsoft frames this as responding to customer feedback, one has to wonder if they’ve simply acknowledged what was already obvious to the development community. The 18-month support cycle has been problematic since its introduction:
Enterprise Reality Gap: Most enterprise organizations operate on annual budget cycles and 24-36 month technology refresh plans. An 18-month support cycle forced uncomfortable conversations about upgrades mid-cycle.
CI/CD Myth: The idealistic “just upgrade continuously” approach works wonderfully in conference presentations, but rarely matches reality in complex enterprise environments with large codebases.
Resource Constraints: With developer shortages and competing priorities, many teams struggled to allocate resources for mandatory upgrades every 18 months.
A Negative Example: The Upgrade Ordeal
Consider “Contoso Enterprises,” a mid-sized company running several critical applications on .NET 7 (STS). Their last upgrade to .NET 7 took months, involving:
- Dependency Audit: Over 40 third-party NuGet packages, half of which either lagged behind .NET 7 support or required beta versions. Resolution involved contacting maintainers, waiting, or forking packages.
- Regression Testing: Legacy workflows required end-to-end manual testing, eating up QA bandwidth for weeks.
- Environment Sync: Upgrades across dev, staging, production, and DR environments. Each step uncovered new surprises and configuration pitfalls.
- Business Disruption: Two urgent business initiatives had to be deprioritized because the upgrade consumed all available developer capacity.
All this for a release with a lifecycle so short that, by the time stability returns, the next upgrade is looming. The newly extended 24-month window is helpful—but for Contoso, it’s still a sprint compared to the marathon pace of real enterprise change management.
Is 24 Months Actually Enough?
The extra six months is undoubtedly helpful, but let’s not get too excited. Many organizations still face significant challenges:
- Dependency Hell: Upgrading a non-trivial application isn’t just about changing the target framework. It involves ensuring all dependencies are compatible, which can be a substantial undertaking.
- Testing Burden: Comprehensive testing of complex systems after framework upgrades remains resource-intensive.
- Still Not Aligned: Even at 24 months, the support cycle doesn’t perfectly align with most organizations’ planning horizons.
STS vs. LTS: A Quick Comparison
| Release Type | Support Length | Typical Use Case |
|---|---|---|
| STS | 24 months | Early adopters, feature-driven |
| LTS | 36 months | Stability-focused, enterprise apps |
Practical Recommendations
Given this change, here’s what I recommend:
- Update Your Planning: If you’re on .NET 9, you now have until November 2026 instead of May 2026. Use this time wisely.
- Evaluate LTS for Critical Apps: If stability and long-term support are priorities, consider sticking with LTS releases like .NET 8 or .NET 10 in the near future.
- Automate Testing: The best way to reduce upgrade pain is comprehensive automated testing. Invest now to make future upgrades less painful.
- Keep Dependencies Current: Regular dependency updates reduce the shock of framework upgrades. Consider tools like NuGet’s dependency management features or GitHub’s Dependabot.
- Know Your Lifecycle: If your business can’t keep up with the STS treadmill, LTS remains your best friend.
The Bottom Line
Microsoft’s extension of STS support to 24 months isn’t revolutionary—it’s a pragmatic adjustment to reality. It acknowledges that the software development lifecycle in most organizations moves more deliberately than the idealized CI/CD paradise often depicted.
While the extra six months is welcome, it doesn’t fundamentally change the equation. Organizations still need thoughtful strategies for managing .NET upgrades, balancing between staying current and managing limited development resources.
Is it a generous gift? Perhaps. Or maybe it’s just Microsoft catching up with what most of us already knew: 18 months was simply too short for comfort.
What’s your take on the extended support timeframe? Will it materially change your .NET upgrade strategy, or is it just kicking the can a little further down the road?
Note: This policy change specifically applies to the modern .NET releases (formerly known as .NET Core) and not the legacy .NET Framework, which follows a different support lifecycle.