The support window is the spec.
On Tuesday 10 November .NET 11 launches, and on the same day .NET 8 and .NET 9 stop getting security patches. The launch will get the attention. The deadline is the part that matters for anyone running software built in the last three years.
Microsoft ships .NET 11 on Tuesday 10 November, with .NET Conf running from the 10th to the 13th. Union types in C# 15, async handled by the runtime, vector search in EF Core. There will be keynotes and benchmark charts, and most of the coverage will be about that.
The same date carries a quieter line. .NET 8 and .NET 9 both reach end of support on 10 November 2026. The software keeps running. It just stops getting security fixes, and Microsoft stops offering technical support for it.
.NET 8 was the long-term release of late 2023, which makes it the sensible default a lot of systems were built on in 2024 and 2025. Booking tools, internal dashboards, the API behind someone's app. If you commissioned bespoke software in that window, there is a fair chance it sits on one of the two versions going out of support this week.
Why two versions end on the same day
Microsoft alternates between long-term releases, supported for three years, and standard-term releases. In 2025 it stretched standard-term support from 18 months to 24, starting with .NET 9. That moved .NET 9's end date from May to November, onto the same day as .NET 8. One deadline instead of two is tidier, but it also means everyone upgrading lands in the same week.
The same change produces a quirk worth knowing. .NET 10, the current long-term release, is supported through November 2028. .NET 11, the new standard-term release, is supported for two years from Tuesday, which also takes it to November 2028. For this one cycle the short-term release does not buy you a shorter life.
| Version | Type | End of support |
|---|---|---|
| .NET 8 | Long-term | 10 November 2026 |
| .NET 9 | Standard-term | 10 November 2026 |
| .NET 10 | Long-term | November 2028 |
| .NET 11 | Standard-term | November 2028 |
What we would land on
For a system that needs to be boring, .NET 10. It is the release Microsoft points people to, it has been in production for a year, and the libraries a typical business app leans on have caught up with it. For something new where the team wants the language features, .NET 11 is a fair call now that the support window matches. What we would not do is upgrade to 11 on launch week for an existing system just because it is the newest number. Let the first patch releases land.
A framework version is not a detail of the build. It is a date on which the build starts to age.
Put the date in the spec
The real lesson is not about .NET. Every runtime, framework and mobile SDK has a support window, and most project specs never mention it. The quote covers the build. Nobody writes down that the thing will need a planned upgrade in three years, so when the date arrives it reads as a surprise cost rather than scheduled maintenance.
We now put the end-of-support date for every major dependency into the handover document, next to the hosting details and the domain renewal. It changes the conversation. An upgrade booked eighteen months out is a line in a maintenance plan. An upgrade discovered after a security advisory is an incident.
What to check this week
- 01Find out which runtime your systems run on. The project file names the target framework, and any developer can read it in a minute.
- 02If it is .NET 8 or 9, nothing breaks on Tuesday, but the clock on unpatched vulnerabilities starts. Book the move to .NET 10 rather than leaving it open.
- 03Check the hosting too. A managed platform may retire the old runtime image on its own schedule, which can be sooner than you expect.
- 04Write the next end-of-support date down somewhere a non-developer will see it.
Launch day is when the new version gets attention. The end of support is when the old one needs it. Plan for the second date when you plan the first.