.NET 10 vs .NET 11: picking a target before 10 November

The .NET 10 vs .NET 11 question has a wrong answer that sounds right: "take the LTS, STS is only 18 months." That stopped being true with .NET 9. Microsoft extended Standard Term Support from 18 to 24 months, which narrows the real support gap between .NET 10 and .NET 11 to roughly a year — and changes who should pick which.

You have until 10 November 2026 to decide. That is the day .NET 8 and .NET 9 both reach end of support, and it is also the month .NET 11 is expected to ship.

The dates, from the support policy rather than a blog

Microsoft's support policy page is the only source worth quoting here, because the secondary coverage on this is unreliable:

Version	Released	Type	End of support
.NET 8	14 November 2023	LTS	10 November 2026
.NET 9	12 November 2024	STS	10 November 2026
.NET 10	11 November 2025	LTS	14 November 2028
.NET 11	Expected November 2026	STS by cadence	Not yet published

Two things in that table are worth saying out loud. First, an LTS and an STS expire on the same day, which is unusual and catches people who assume LTS always buys more runway. Second, Microsoft has not published an end-of-support date for .NET 11, and the "What's new in .NET 11" page commits only to general availability "expected in November 2026" — no day. Several pages currently ranking state 10 November as a hard GA date. Treat that as a guess until Microsoft prints it.

Why .NET 9 did not end in May 2026

If you find a page saying .NET 9 support ended on 12 May 2026, it is not wrong so much as out of date. That was the original date under the old 18-month STS window. In a September 2025 announcement, Microsoft extended STS support to 24 months beginning with .NET 9, moving its end of support to 10 November 2026.

The rule now reads: STS gets 24 months, which works out to 12 months after its successor ships. LTS is unchanged at three years. That is the arithmetic the rest of this decision runs on.

What .NET 10 vs .NET 11 actually buys you

Assume .NET 11 ships in November 2026 as STS with a 24-month window. You get support to roughly late 2028. .NET 10 LTS is supported to 14 November 2028. On support duration alone, the two are close enough that it should not be the deciding factor — which is the opposite of the conventional advice.

So decide on the things that actually differ:

	.NET 10 (LTS)	.NET 11 (STS)
Support ends	14 November 2028	Not published; ~late 2028 by cadence
Status today	Shipped, a year of production use behind it	Release candidate 2, with a go-live licence
Language	C# 14	C# 15 — union types, closed hierarchies, collection expression arguments
Hardware floor	Unchanged	Raised on x64 and Windows Arm64
Upgrade cadence implied	Next move 2028	Next move within about a year

The cadence row is the real commitment. Choosing .NET 11 is choosing to upgrade annually, because each STS hands you a shorter runway than the last LTS did. For a team with mature CI and good test coverage, an annual .NET bump is routine work. For a team that found this upgrade hard, picking STS guarantees doing it again next year.

The .NET 11 hardware floor, which nobody is costing

This is the part missing from every comparison we read, and it is the one that can stop a migration dead. .NET 11 raises its minimum hardware requirements, and an application that does not meet them does not start. The runtime prints:

The current CPU is missing one or more of the baseline instruction sets.

On x86/x64 across Apple, Linux and Windows, the JIT and AOT baseline moves from x86-64-v1 to x86-64-v2. In practice that guarantees CX16, POPCNT, SSE3, SSSE3, SSE4.1 and SSE4.2 rather than just CMOV, CX8, SSE and SSE2. Microsoft notes this matches what Windows 11 requires and what every x64 chip still officially supported by Intel and AMD provides — the last ones without it left support around 2013.

Be careful with the secondary reporting here. At least one trade publication states that x64 on Windows and Linux now requires x86-64-v3. Microsoft's own table does not say that: x86-64-v3 — which adds AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT and MOVBE — is the new ReadyToRun target for Windows and Linux, not the floor to launch. The distinction matters: miss the baseline and nothing runs; miss the R2R target and you pay extra jitting at startup on otherwise supported hardware.

On Arm64 the Windows baseline gains LSE, with the R2R target moving to armv8.2-a + RCPC. Linux and Apple minimums are unchanged, so Raspberry Pi class devices and M1 Macs are unaffected, though Linux Arm64 R2R now targets armv8.0-a + LSE and may jit more at launch.

Who this bites: anyone on older on-premises hardware, pinned older VM families from a cloud migration nobody revisited, or embedded and industrial devices. Check before you plan, not after. On Linux:

/lib64/ld-linux-x86-64.so.2 --help | grep x86-64-v
grep -o 'sse4_2\|popcnt\|cx16' /proc/cpuinfo | sort -u

This is the same shape of problem as Windows Server 2016 going end of support: the deadline looks like a software decision and turns into a hardware inventory.

What else is in .NET 11 worth upgrading for

C# 15 is the headline, and union types and closed hierarchies are genuinely useful for domain modelling — the kind of thing that removes a category of defensive code from a codebase. They are also a language feature you can adopt gradually rather than a reason to rush a runtime.

Runtime Async is the change people are most likely to misread. It replaces compiler-generated async state machines with runtime-managed suspension, and the visible payoff is dramatically shorter live stack traces — Microsoft's own example drops from 13 frames to 5. But it remains a preview feature requiring explicit opt-in:

<PropertyGroup>
  <Features>runtime-async=on</Features>
</PropertyGroup>

What has changed is that a net11.0 project no longer needs EnablePreviewFeatures to turn it on, and the runtime libraries themselves now ship compiled with it. The DOTNET_RuntimeAsync and UNSUPPORTED_RuntimeAsync environment variables have been removed, so if you have anything setting those, it is now dead configuration — opt out per project with <UseRuntimeAsync>false</UseRuntimeAsync> instead.

The rest is performance work you get for free: ReadyToRun now specialises Comparer<T>.Default and EqualityComparer<T>.Default, which Microsoft benchmarks at up to 20x for collection operations that relied on the default comparer; interface dispatch on non-JIT platforms such as iOS improves by up to 200x in interface-heavy code; and Guid.NewGuid() on Linux gains about 12% by moving to getrandom(). If you run .NET on iOS through MAUI, that dispatch change is the single most interesting number in the release.

So which one

Take .NET 10 if you are in a regulated environment where runtime changes need sign-off, you are mid-migration from .NET Framework or .NET 8 and want one move rather than two, your hardware estate is old or unaudited, or your team upgrades on a multi-year rhythm. This is most teams, and it is the safe answer for a reason: it is shipped, it has a published end date, and it does not raise your hardware floor.

Take .NET 11 if you already upgrade annually without drama, you want C# 15 in your domain model now, you are starting something greenfield in the next few months, or you have a dependency that will require it — EF Core 11, for instance, is expected to need the .NET 11 SDK and runtime, so library timelines may make this decision for you.

Do not stay on .NET 8 or 9 past 10 November without a written decision and a date. Unsupported means no security patches, and the first critical runtime CVE afterwards turns a planned upgrade into an unplanned one. If you concluded earlier that .NET 8's end of support was a reason to move off .NET entirely, that remains a legitimate answer — but it is a bigger programme than a runtime bump and it does not fit in the next four weeks.

What to do in the next four weeks

1. Inventory runtimes, not projects. dotnet --list-runtimes on every host, and the target framework of every deployed artefact. The gap between what the repo targets and what production runs is where the surprises live.
2. Audit the CPU baseline before you even evaluate .NET 11. If any host fails x86-64-v2, .NET 10 is your only option this cycle and the hardware is a separate project.
3. Upgrade to .NET 10 first regardless. It is a supported LTS, the step from 8 or 9 is small, and it leaves 11 as an independent decision rather than a coupled one.
4. Run the upgrade assistant and your full test suite on one service, then measure. Most of the risk in a modern .NET major upgrade is in dependencies and analyzers, not the runtime. Where a codebase has no tests to run, writing them is the first task, not the upgrade — the approach we described for refactoring 300,000 lines of legacy code applies here too.
5. Write down the next date. 14 November 2028 if you land on 10. If you land on 11, put a reminder at 12 months, because that is the cadence you have just signed up to.

The decision that costs real money is not 10 versus 11. It is whether this upgrade is a four-week task or a six-month one — and that is determined by test coverage and dependency hygiene rather than by anything on Microsoft's roadmap. If you are looking at a .NET estate where nobody is confident what the four-week version looks like, working that out is the modernisation work we do.