What is coming in .NET 11, and does it change anything for you?

If your business runs on software written in .NET, you may have heard that .NET 11 is on its way. Perhaps a developer mentioned it, or a supplier's newsletter did, and now someone has asked whether you need to do anything about it.

For most organisations, the answer is no. A new release changes nothing for an application until somebody chooses to move it. The job that matters in the next ten days is the one already on the calendar: moving off .NET 8 and .NET 9, which both reach end of support on 10 November. This article explains the release rhythm so you can see why, and gives you a simple rule for deciding which release your systems should sit on.

Everything below is as of 31 October 2026. .NET 11 has not been released yet.

What is known today

Microsoft published .NET 11 Release Candidate 2 on 13 October. A release candidate is a version that is feature-complete and being tested in public before the final release. Microsoft says this one comes with a go-live support licence, which means it will support you if you run it in production.

Microsoft's What's new in .NET 11 page says general availability, meaning the final release, is expected in November 2026. That is all it says at this point. There is no confirmed release day to plan around, and no published end-of-support date for .NET 11 yet.

The yearly rhythm

Microsoft's .NET support policy sets out a regular pattern:

• A new major version of .NET is published every year in November.
• Even-numbered releases are long-term support (LTS) releases, with three years of free support and security patches.
• Odd-numbered releases are standard-term support (STS) releases, with two years.

So .NET 8 (LTS) and .NET 9 (STS) are the ones ending on 10 November. .NET 10 is the current long-term release and is supported until 14 November 2028. .NET 11 will be a standard-term release, and on the same pattern .NET 12 would be the next long-term one.

Seen that way, the yearly announcement works more like a calendar than a prompt for action. Every November there is a new version, and every November one or two older ones are close to the end of their support. The sensible response is a planned cycle, not a reaction to each release.

What .NET 11 brings, in one paragraph

Mostly things for developers. Two are worth a plain-English line, both named on the What's new page:

• Runtime async. A change to how the runtime handles code that waits (for a database, a web service or a file) which gives cleaner error traces and less overhead. In practice that can mean slightly faster applications and easier fault-finding.
• C# 15. The next version of the language developers write in. Headline additions include union types, which let code say "this is one of these three things" and have the compiler check it.

Neither is a reason to move a stable business system. They are reasons developers will be pleased when you do move.

A decision rule

For business-critical applications, the pattern that works for most organisations is:

1. Target long-term support releases. They give three years between forced moves, which fits the way budgets and change windows actually work.
2. Move on a planned cycle. Once a long-term release is in place, schedule the next move well before the old one ends, rather than in the final fortnight.
3. Use a standard-term release only when you can upgrade within a year. That suits a team with strong automated tests and a regular release habit. It is a deliberate choice, not a default.

The date that matters most is the one your application is already facing. If you are on .NET 8 or .NET 9, that is 10 November, and the practical upgrade guide for .NET 8 points at .NET 10, the long-term release. Our guide to what out of support means covers the wider picture if you want to explain it to a colleague or board.

What not to do

A go-live licence on a release candidate is real support, and for some teams it is a useful way to prepare. It is not a reason to put a live, business-critical system on a release candidate when it has no particular need of what the release adds. Waiting for the final release costs you a few weeks and removes a variable. If a developer wants to move to .NET 11 early, ask what they gain by doing it, and what happens if something goes wrong.

A sensible first step

In the next week or so, ask your developers or your IT supplier three questions:

• Which version of .NET is each of our business-critical applications on?
• What is our upgrade cycle, and when is the next move due?
• Who decides, and who signs it off?

If the answers are vague, that is useful information in itself, and it is better to learn it now than on 10 November. Write the answers down in one place, with a date for the next review.

To find out where a particular system stands, a software health audit gives you an independent view, and our software care service looks after systems on a planned cycle so the yearly release is a diary entry rather than a worry. Once .NET 11 is released, we will publish a technical article on what it brings.