Microsoft's .NET release cycle and the LTS upgrade trap

The two release tracks: LTS vs STS

The track a version falls into is determined by whether the version number is even or odd. There is no other criterion. Microsoft decided this in 2020 and has held it since.

A scheduling note: .NET 9 STS (released November 2024) is supported until November 10, 2026 -- the same date as .NET 8 LTS. Earlier STS releases like .NET 7 ran on the old eighteen-month clock, which is why their bars on the chart above are shorter.

When do .NET 11 and .NET 12 arrive?

Microsoft has not published a release date for either .NET 11 or .NET 12. What is published is the cadence, and it has held since 2020: a new major version of .NET every November, even-numbered releases on Long-Term Support, odd-numbered releases on Standard-Term Support.

Read against that cadence -- and this is an expectation drawn from the pattern, not a date Microsoft has committed to -- .NET 11 would arrive in November 2026 as an STS release, and .NET 12 in November 2027 as an LTS release. Treat both as pencil, not ink.

What is fixed is the current LTS: .NET 10 shipped November 11, 2025 and is supported through November 14, 2028. When you plan a platform move, anchor it to that published date and the LTS you are actually on, not to a projected .NET 11 or .NET 12 Microsoft has not scheduled. Plan against the calendar, not the roadmap rumors. The same discipline applies beyond .NET -- SQL Server carries its own deadlines, the nearest covered in the SQL Server 2016 end-of-support guide.

The hard bridge and the easy bridge

In 2016, Microsoft began rebuilding .NET from the ground up. The legacy product was .NET Framework, a Windows-only stack that had grown organically since 2002. The new product started as .NET Core, then unified everything under the .NET 5 name in 2020 and dropped the “Core” suffix. The new line runs on Mac and Linux as well as Windows. The old line doesn't.

That decoupling is also where the short support cadence comes from. Framework rode the long Windows OS lifecycle for its patches. Modern .NET runs on its own clock, and the clock is shorter.

Crossing that bridge -- taking an application from .NET Framework to modern .NET -- is structural work. Rewriting foundational code. Replacing libraries that didn't make the jump. Re-testing the whole surface area. The teams that have done it remember it as quarters or years of effort, not days. The companion page .NET Framework migration risk by version covers what specifically breaks on that crossing.

Crossing between modern versions is a different operation entirely. .NET 8 to .NET 10 uses the same runtime (the underlying engine the application runs on), the same C# patterns, the same APIs. For a healthy application it's a version bump in the project file, a package restore, and a test run. Days to weeks, not quarters. The biggest friction is usually third-party library updates and the handful of breaking changes Microsoft documents in the release notes.

The two operations share the word “upgrade.” They share almost nothing else. That distinction is the whole reason the trap exists.

How the trap works

Teams that survived the Framework migration land on a modern LTS -- usually .NET 6, 8, or 10 -- and breathe out. The hard part is done. The codebase is finally modern. LTS becomes set-it-and-forget-it: a track the team doesn't have to think about for three years.

Three years goes faster than it feels. When the ticket to move from the current LTS to the next appears, the team makes two assumptions. Both are wrong:

• The new upgrade will hurt as much as the Framework migration did. (It won't. It's days to weeks for a healthy app, not months to years.)
• Therefore it can wait until there's slack in the roadmap. (There won't be slack. The deadline arrives anyway.)

So the work slips. November comes. The current LTS reaches end of support. The codebase that was modern last week is unpatched today. The team that did everything right two years ago is now running an unsupported runtime, and the auditor, the cyber carrier, or the PE diligence team is the one who finds out first.

The trap isn't carelessness. It's pattern-matching on the wrong precedent. The Framework migration taught these teams that .NET upgrades are dangerous, expensive, and best deferred. Modern .NET upgrades are none of those things. But the muscle memory says otherwise, and the muscle memory wins until the calendar catches them.

The budgeting shift

The trap doesn't usually catch engineering teams in isolation. Engineering knows when the support window closes. The trap catches the layer above engineering -- the people deciding what gets a slot in next quarter's roadmap and what doesn't.

The legacy Framework model trained that layer to think of .NET upgrades as rare, expensive, multi-quarter projects with their own line item. Modern .NET doesn't work that way. The upgrade is a recurring maintenance cost -- a few engineer-days every two years for the LTS-to-LTS bump, a few more every November for any service on STS. It needs to live in the engineering operating plan as a recurring line, not get re-discovered each cycle.

Teams that handle modern .NET well are the ones whose planning process treats the next upgrade as already on the calendar the day the previous one shipped. Teams that treat it as a “we'll get to it” item, raised when the deadline gets close, are the teams we see arriving at November with a runtime out of support and no scheduled fix.

What this looks like in practice

The shape of the trap doesn't change much across engagements. The specifics do.

The team migrated to .NET Core 3.1 in 2020, then to .NET 6 in 2022, then stopped paying attention because “we're on modern .NET now.” They're on .NET 6, which reached end of life in November 2024. They didn't notice until a security scan flagged it.

The team is on .NET 8 LTS and considers themselves current. They are. They also have until November 10, 2026, before .NET 8 reaches end of support, and the .NET 10 upgrade isn't on any quarter's plan.

The team adopted an STS version because it had a feature they needed, then missed the support window because the team that requested the feature moved on to other work. The application is now on an unsupported version of modern .NET while still inside the same engineering organization that picked it.

The team consolidated three services onto three different modern .NET versions, each current at the time. Now each service needs its own upgrade plan, and the consolidation is more work than upgrading any of them individually would have been.

The team has been on .NET 8 since 2024 and considers it “modern enough.” Then a routine NuGet upgrade (updating one of the off-the-shelf code libraries the application depends on) quietly requires .NET 10. The package that does the thing they actually need has already dropped .NET 8 support. A senior engineer in an interview asks how often the team takes runtime upgrades. The runtime is still patched. The surroundings have moved.

None of these are catastrophic on their own. They're cheap to fix when they're caught early and progressively more expensive every release cycle the team postpones.

What to do about it

If you're on a modern LTS today, the upgrade is small and the deadline is real. Treat the November release of the next LTS as the start of the upgrade window, not the end of it. Teams that schedule the move in the quarter the new LTS ships almost never miss the support deadline.

If you're still on .NET Framework, the calculus is different. That's the hard bridge, and the cost model and risk profile are nothing like the LTS-to-LTS pattern described above. The .NET Framework migration risk page covers what to expect.

If you don't know which side of the bridge your applications sit on, that's part of what a Modernization Shield engagement diagnoses.