.NET 11 Unpacked: Why I'm Recommending STS This Time

Table of Contents

• What to Expect From This Article
• A Short History of LTS and STS
• Why There Are Two Tracks at All?
• Why Microsoft Extended STS to 24 Months?
• The Catch: The Same End Date
• Why .NET 11 Might Be the Better Migration Target Right Now
• "But It's Not Battle Tested Yet"
• When .NET 10 Is Still the Right Call
• What I'd Recommend, by Situation
• A Pre-Upgrade Checklist
• Wrapping Up

What to Expect From This Article

For years, my advice on .NET upgrades was simple: plan around LTS releases. Skip the STS ones unless you have a very good reason.

This November, that advice is not as strong as before. .NET 10 (LTS) and .NET 11 (STS) both reach end of support on November 14, 2028. Same day. One of them is a year newer.

In this first article of the .NET 11 Unpacked series, I'll walk through where LTS and STS came from, why the two tracks exist, and why, for a lot of teams right now, .NET 11 may be the better upgrade target. I'll also cover when it isn't.

A Short History of LTS and STS

The two-track model is almost as old as .NET Core itself, which has been around since 2016. But the rules have changed several times.

A few things stand out.

STS never meant "Short." The official name is Standard Term Support, and Microsoft's policy page still notes that STS releases were previously known as Current releases.

Most of us (me included) read the "S" as "Short" for years. That small misreading did a lot of damage to how people see these releases.

STS support has only ever grown. It went from "a few months after the next release" to 18 months, and now to 24. So I guess "standard" is even more suitable wording here.

By the way, LTS has stayed at three years the whole time. It hasn't changed.

The 2025 change is the one that matters here. Under the old rule, an STS release was supported for 6 months after its successor shipped. Under the new rule, it's 12 months. That one change lines up the end date of every STS release with the LTS release before it.

Why There Are Two Tracks at All?

The two tracks serve two kinds of teams. LTS is for teams that want to upgrade as rarely as possible. STS is for teams that want new features and performance gains every single year.

What the tracks don't differ in is quality standards. The .NET release policies say LTS and STS releases differ only by support duration, and that the team uses the same engineering and release processes for both, including for security, compatibility and reliability. The support policy page puts it even more plainly: the quality of all releases is the same.

So an STS release isn't a beta, a preview or a "test" version of the next LTS. STS is a completely different concept. It's a full production release with a shorter warranty.

Why Microsoft Extended STS to 24 Months?

The 2025 extension wasn't really about STS users. It fixed a problem for LTS users (me included).

More and more of .NET now ships out of band, outside the yearly release: .NET Aspire, Microsoft.Extensions.AI and the C# Dev Kit, for example. Those components sometimes need package versions from the newest yearly release. So a team that thought it was fully on LTS could pull in a few STS packages without noticing. Under the 18-month rule, those packages lost support six months before the LTS runtime they ran on.

Moving STS to 24 months closed that gap: the STS packages now stay supported exactly as long as the LTS release before them. The side effect is the one this article is about. Every STS release now retires on the same day as the previous LTS.

The Catch: The Same End Date

Under the 24-month rule, the STS release that ships a year after an LTS release retires on the same day as that LTS. This November is the first time it happens with a brand-new release on the table.

Take a look at the chart:

.NET 10 shipped a full year before .NET 11, yet both stop getting patches on November 14, 2028. Picking the LTS this cycle buys you no extra support at all.

The chart also shows the other half of the story. .NET 8 and .NET 9 both reached end of support on November 10, 2026. If you're still on either one, you're no longer getting security fixes.

Act now! Or whenever you have time for addressing the technical debt.

Why .NET 11 Might Be the Better Migration Target Right Now

If you haven't started your .NET 10 migration yet, going straight to .NET 11 gets you everything .NET 10 offers, plus a year of improvements, with no shorter runway.

1. The same end-of-support date. Both versions are supported until November 14, 2028. Choosing .NET 10 buys you zero extra days.

2. The same support. Same monthly patches on Patch Tuesday, same security fixes, same engineering process. The only thing LTS adds is time, and this cycle it doesn't even add that.

3. A newer language. .NET 11 ships with C# 15, which brings union types, closed hierarchies, extension indexers, labeled break and continue, and collection expression arguments. Union types alone have been one of the most requested C# features for years.

4. Runtime, library and SDK improvements. Every release brings JIT, GC and library work. .NET 11 also cut the SDK install size on Linux and macOS, and adds new APIs across compression, Base64, process handling and SIMD.

5. Better tooling and security hardening. You get the newest SDK, analyzers and Visual Studio support, and every security fix that went into the platform during the past year.

6. A shorter jump next time. Both versions retire on the same day, so you'll move off either one by November 2028. From .NET 11, the next LTS (.NET 12) is one version away. From .NET 10, it's two.

"But It's Not Battle Tested Yet"

That's the most common objection, and it's a fair one. Here's why I think it's smaller than it looks.

It's actually been public for nine months. .NET 11 Preview 1 shipped in February 2026, followed by monthly previews and three release candidates from September onward. Microsoft's support policy describes release candidates as typically being "go-live" builds, supported in production. So teams could run .NET 11 in production for weeks before GA.

Though, I don't really recommend using preview versions for your production deployments. It's not the best idea. Always wait for the full releases.

STS isn't a lower quality bar. Same engineering process, same security and compatibility testing as LTS. The label tells you how long it's supported, not how well it's built.

Your migration takes time anyway. Most teams I know need weeks or months to upgrade a real system. Patches ship every month, so by the time you're in production, .NET 11 will already have a few servicing releases behind it.

The real risk is your dependencies, not the runtime. A brand-new release rarely breaks because of the runtime itself. It breaks because a library, a tool or a hosting platform hasn't caught up yet. That's something you can check up front (see the checklist below).

.NET 10 is also new to you. If you've never run .NET 10 in production, it's untested in your system too. Either way, you're testing a new version against your own code.

If you want an extra safety margin, there's a simple middle ground: start the migration on .NET 11 now, and go to production after the first one or two patch releases.

When .NET 10 Is Still the Right Call

.NET 11 isn't the right answer for everyone. Stick with .NET 10 if any of these apply.

• Your hosting platform only supports LTS. AWS Lambda, for example, has historically offered managed runtimes only for LTS versions of .NET. On an STS release, you'd need a container image or a custom runtime. Check what your cloud services support before you commit.
• A critical dependency hasn't caught up. A library, an APM agent, an ORM provider or an internal package that doesn't support .NET 11 yet can block you on its own.
• Company policy says LTS. Some organizations, especially regulated ones, only allow LTS versions in production. Arguing with that policy may cost more than the upgrade saves.
• You run on older hardware. .NET 11 updates its minimum hardware requirements on some platforms. Check them if you deploy to older machines.
• You're already well into a .NET 10 migration. Finish it. You'll have the same end date, and moving from 10 to 11 later is a small step if you want it.
• You use .NET MAUI with the old compatibility package. The Xamarin.Forms compatibility package is gone in .NET 11, so that migration comes first.

What I'd Recommend, by Situation

Here's how I'd decide, depending on where your team is today.

If you're on .NET 8 or 9, the most important point isn't 10 versus 11. Both versions went out of support on November 10, 2026, so you're running without security patches right now. Pick a target and start.

A Pre-Upgrade Checklist

Before you change TargetFramework to net11.0, work through these:

✅ Hosting: confirm every place you deploy (cloud services, serverless, container base images, CI agents) supports .NET 11.
✅ Dependencies: list your NuGet packages (dotnet list package --outdated is a good start) and confirm the critical ones support .NET 11.
✅ Tooling: check your IDE, analyzers, test runners, profilers and APM agents.
✅ Hardware: compare your oldest production machines against the .NET 11 minimum requirements.
✅ Breaking changes: read the breaking-change notes for every version you're skipping, not only .NET 11.
✅ Pin the SDK: update global.json and your CI images so everyone builds with the same SDK.
✅ Test for real: run the full test suite, plus load or benchmark tests on your hot paths.
✅ Roll out gradually: staging first, then a canary or a small slice of traffic.
✅ Plan the exit: put November 2028 in your roadmap now and decide when you'll move to .NET 12.

Wrapping Up

"Always pick LTS" is still a good default. But it's a rule of thumb, not a law, and this year the numbers say something different. .NET 10 and .NET 11 retire on the same day, they get the same support, and they're built to the same standard. One of them is simply a year newer.

I really think this is a positive change by the .NET team.

So if you're about to start an upgrade, look at .NET 11 seriously. Check your platform and dependencies first. If nothing blocks you, you may find that the STS release is the better deal.

Next in .NET 11 Unpacked, I'll dig into the features themselves, starting with C# 15. Which .NET version are you targeting right now, and why? Let me know in the comments.

Let's stay connected!

• 💼 Connect with me on LinkedIn
• 💻 Explore my projects on GitHub
• 📱 Follow me on X
• 🎥 Watch my videos on YouTube
• 💬 Let's Chat on Discord