.NET 9 vs .NET 10 Planning Before .NET 8 End of Support — when and how should I migrate?
Choose whether to step through .NET 9 or hold for .NET 10 as teams plan around support windows, container image churn, and ASP.NET compatibility changes.
Blockers
- Forwarded headers ignore X-Forwarded-* values from unknown proxies.
- Introduces disabled cookie login redirects for known API endpoints and new obsoletions around WebHostBuilder, Razor runtime compilation, and WithOpenApi.
Who this is for
- enterprise
- microservices
- low-ops
Candidates
Adopt .NET 9 now and schedule a second hop to .NET 10
As of 2026-04-02, .NET 9 is the current Standard Term Support release. Microsoft lists .NET 9 support from 2024-11-12 through 2026-11-10, which is the same end-of-support date Microsoft lists for .NET 8 LTS. For teams that want the newest runtime and SDK immediately, .NET 9 is viable, but it does not extend the support runway past .NET 8. Verified migration caveats include .NET 9 container images no longer installing zlib, ASP.NET Core 9 forwarded headers now ignoring X-Forwarded-* values from unknown proxies, and .NET 9 SDK tooling requiring newer Visual Studio support to target net9.0.
When to choose
Use this when you need .NET 9 features now and already expect another planned runtime upgrade in 2026. It fits teams with strong release discipline that can absorb a short-lived STS adoption and still move again before 2026-11-10.
Tradeoffs
You get current platform features sooner, but you accept a shorter support runway and likely two production upgrade cycles before .NET 8 support ends. Container and tooling changes also create churn without buying extra support time.
Cautions
Do not treat .NET 9 as a support-window bridge past .NET 8. As of 2026-04-02, Microsoft's lifecycle page shows both .NET 8 and .NET 9 ending support on 2026-11-10. Check reverse-proxy behavior, Dockerfiles that assume zlib, and Visual Studio fleet versions before committing.
Stay on .NET 8 and move directly to .NET 10 LTS
As of 2026-04-02, .NET 10 is the current Long Term Support release. Microsoft lists .NET 10 support from 2025-11-11 through 2028-11-14, giving materially longer runway than .NET 9. This is the cleaner planning path when the real objective is to get off .NET 8 before its 2026-11-10 end of support without doing an intermediate STS rollout. The main verified migration blockers are different from .NET 9: default .NET 10 Linux image tags now use Ubuntu 24.04, Debian-based images are no longer provided, and ASP.NET Core 10 introduces compatibility changes including disabled cookie login redirects for known API endpoints plus new obsoletions around WebHostBuilder, Razor runtime compilation, and WithOpenApi.
When to choose
Use this when support longevity and fewer upgrade waves matter more than getting .NET 9 features immediately. It is the better default for enterprises, low-ops teams, and containerized services that want one deliberate migration before .NET 8 support ends.
Tradeoffs
You avoid a short-lived STS stopover and gain LTS coverage into 2028, but the single jump is broader and may surface more ASP.NET and container-image work at once. Teams tied to Debian-based official images need their own image strategy.
Cautions
Test container behavior explicitly if you currently depend on default image tags or Debian package assumptions. For ASP.NET Core apps, validate API auth flows and remove or replace obsolete patterns before rollout.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # ".NET 9 vs .NET 10 Planning Before .NET 8 End of Support — when and how should I migrate?"