What is new in .NET 11, and should you move from .NET 10?

.NET 11 was released yesterday, 10 November 2026. There is plenty of interest in it. If you run production applications on .NET 10, though, the practical questions are whether any of it is worth an upgrade now, and what the upgrade would cost you.

This article is a tour of the main changes, a look at what could break, and a decision guide. It is as of 11 November 2026, and it relies on Microsoft's announcement, the what's new overview and the C# 15 page. When we read the overview page on 11 November it was still labelled as covering release candidate 2, so where the announcement and the overview differ we have followed the announcement. We previewed the release on 31 October in what is coming in .NET 11, and yesterday's article for non-specialists, .NET 8 and .NET 9 are out of support today, covers the other half of the news.

Support: the same end date

Microsoft's support policy page lists:

Both end on the same day, so moving from .NET 10 to .NET 11 buys you features rather than extra time. If you are on .NET 10 you already have a supported version, and the question becomes whether a feature is worth an upgrade now, and another upgrade next year.

The language: C# 15

C# 15 is the default for projects targeting net11.0. The features listed on the C# 15 page include:

• Union types: a union declaration for a value that is exactly one of several types, with the compiler checking switch expressions for completeness.
• Closed hierarchies: a closed class can only be derived from within its own assembly, so the compiler knows every direct subtype and can check pattern matching.
• Collection expression arguments: a with(...) element passes arguments, such as a capacity or a comparer, to the collection being created.
• Extension indexers and labelled break and continue for nested loops.
• Memory safety: still a preview effort that needs LangVersion set to preview, and not something to build production code on yet.

Here is the union example, adapted from Microsoft's page into a single Program.cs (top-level statements first, then the type declarations, as C# requires). It is illustrative: we have not compiled it, and it needs the .NET 11 SDK.

Pet pet = new Dog("Rex");

string name = pet switch
{
    Dog d => d.Name,
    Cat c => c.Name,
    Bird b => b.Name,
};

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

If you add a fourth case to Pet and forget to handle it, the compiler tells you. That is the practical value: the "forgotten case" bug moves from runtime to build time. It is useful for modelling states in business rules, and less obviously useful if your code is mostly CRUD.

Runtime and SDK

The runtime changes are mostly performance work: JIT improvements such as fewer bounds checks and better devirtualisation, and faster Native AOT interface dispatch. Expect small gains in some workloads, and measure your own. Runtime Async, which moves async suspension into the runtime and gives cleaner stack traces, is listed as a preview in the announcement. That is more cautious than the release-candidate notes we drew on in October, which did not call it a preview: .NET's own libraries are built with it, but for your own code it stays an opt-in preview. Treat it as an experiment rather than a reason to upgrade.

In the SDK, the most visible changes are that the Native AOT command-line host and a warm MSBuild server are on by default, and that the CLI's own telemetry moves from Application Insights to OpenTelemetry. For testing, dotnet test gains run-level timeouts, failure limits and per-module results directories, and the test templates now support xUnit v3 and NUnit, with new templates for mobile test projects. NuGet gains a minimum package age setting for sources, which Microsoft is careful to say does not replace vulnerability checks.

Libraries, ASP.NET Core and EF Core

Library additions worth knowing about:

• IEEE 754 decimal types (Decimal32, Decimal64, Decimal128)
• Zstandard compression in System.IO.Compression
• System.Text.Json support for C# unions, and JSON Lines output
• LINQ FullJoin
• Experimental post-quantum APIs, including composite ML-KEM

In ASP.NET Core, OpenAPI 3.2 becomes the default for generated documents (check anything that consumes them), union support arrives in JSON handling, validation can be asynchronous, and SignalR can refresh authentication without reconnecting. The announcement says EF Core 11 requires .NET 11, so it moves with the runtime. Its own breaking changes are worth reading separately, including a change of serialiser in the Cosmos DB provider.

.NET MAUI 11

.NET MAUI follows its own support policy, which lists MAUI 11 as released on 10 November 2026 and now gives MAUI 10 an end of support date of 11 May 2027, about six months after its successor shipped. Unlike .NET 10 itself, MAUI 10 does not run to 2028. The headline change is that CoreCLR becomes the default runtime for mobile, replacing Mono, with Native AOT as an opt-in. That brings breaking changes, including a higher minimum Android API level and the end of Android x86 support. If you maintain a MAUI app, read the MAUI section of the breaking changes list before anything else. For background, see how .NET MAUI works.

What could break

Microsoft's breaking changes list is the document to read. It describes itself as a work in progress rather than a complete list, so check it again before you commit to a date. Items that tend to catch production applications:

• Minimum hardware requirements have been raised for x86/x64, to the x86-64-v2 level (SSE4.2 and POPCNT), which matters for older servers and build agents. The Arm64 minimum is unchanged, though precompiled ReadyToRun code may fall back to the JIT on older Arm64 chips.
• Hosting: IHost.RunAsync and StopAsync now throw when a BackgroundService fails.
• Configuration: an empty string in a chained configuration now overrides an earlier provider's value.
• SDK and restore: restore no longer searches the global packages folder for a higher version.

Several of these change behaviour without a compile error, which is another reason for tests.

Should you move from .NET 10?

Our view is that for most business-critical systems, the sensible target remains .NET 10 (our earlier piece on .NET 8 and 9 end of support has the background). The same end date means nothing forces your hand. If a specific feature would remove real complexity, take it. If not, there is no penalty for waiting.

We resell Microsoft licences and look after .NET systems, so we know this ecosystem well; even so, the right choice depends on your system, your team and your tests.

How to try it safely

1. Use a branch. Retarget one project to net11.0 in a branch, not on main.
2. Pin the SDK. Update global.json if you use one, and install the matching SDK on developer machines and build agents. Installing an SDK alone does not retarget anything.
3. Run the whole test suite. If you do not have one worth the name, start with characterisation tests, which pin down current behaviour before you change anything.
4. Check your hosting. Azure's App Service team announced .NET 11 on Linux in preview on 11 September, and we could not confirm general availability on App Service or the container base images on the day, so verify both with your provider before planning a release.
5. Measure. Compare start-up time, memory and throughput under a representative load, not a benchmark.

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
</PropertyGroup>

For the mechanics of a time-boxed upgrade, our .NET 8 to .NET 10 guide applies almost step for step.

A sensible first step

Pick one small, low-risk application, retarget it to net11.0 on a branch, and run its tests and your pipeline. The result will tell you more about your readiness than any summary, ours included.

For help with an upgrade, or with a system you have inherited, our software care service looks after .NET systems, and software integration covers new builds.