.NET 8 and .NET 9 both end support on one day

.NET 8 and .NET 9 lose Microsoft support on November 10, 2026. After that date there are no servicing updates, no security fixes and no technical support for either version, according to Microsoft's end-of-support announcement. Both an LTS release and an STS release expire on the same day, which is unusual and matters: a team that moved from .NET 8 to .NET 9 to buy time bought nothing.

The upgrade target is .NET 10, supported until November 10, 2028. The code side is genuinely small. The side that surprises people is the toolchain, and that one has a purchase order attached.

What actually ends on November 10, 2026?

Support ends, not the runtime. Applications on .NET 8 or .NET 9 keep running after November 10, 2026. What stops is the supply of patches. .NET is Microsoft's cross-platform application runtime and SDK for C#, F# and Visual Basic. Its support policy gives long-term support releases three years and standard-term support releases eighteen months, and this is the date where both clocks happen to stop together.

For a regulated environment that is the whole story. An unpatched runtime fails a security review regardless of whether it still serves traffic, and a zero-day in the runtime after that date has no vendor fix. InfoWorld's note on the looming deadline puts the practical framing well: the choice is .NET 10 or a paid third-party support contract.

How hard is the move from .NET 8 to .NET 10?

For most backend services it is one line. Change the TargetFramework property in the project file:

<TargetFramework>net10.0</TargetFramework>

Developers who have done it describe the change as routine, with breakages confined to specific libraries, tooling and OpenAPI integrations rather than to application code. That matches the shape of the official list of breaking changes in .NET 10, which is short by the standards of a major version.

Two exceptions are worth checking before you schedule the work.

The first is authentication behavior. ASP.NET Core is the web framework that ships inside .NET and handles routing, authentication and JSON endpoints. In .NET 10, an endpoint secured by cookie authentication and marked with the IApiEndpointMetadata interface no longer redirects to a login or access-denied URI. That covers API controller endpoints, minimal API endpoints handling JSON, endpoints using TypedResults, and SignalR endpoints. They now return a status code where they previously returned a redirect. Consider what that does to a single-page application whose fetch layer quietly followed the redirect and parsed the login page: it now sees a 401, which is more correct and also a different code path. Duende's review of the .NET 10 upgrade traps covers the authentication side in detail.

The second is OpenAPI. Entities inside the OpenAPI document, such as operations and parameters, are now typed as interfaces, with separate concrete implementations for inlined and referenced variants. Code that generates or post-processes documents needs updating. Code that merely serves them does not.

The tooling bill nobody budgeted

Here is the part that turns a quick migration into a procurement conversation.

Requirement	Version needed	Licence cost
Load the .NET 10.0.100 SDK	Visual Studio 17.14+	None on a current 2022 install
Target net10.0 in the IDE	Visual Studio 2026 (18.0)	Free with a subscription; extra for perpetual
Build on CI or command line	.NET 10 SDK only	None

Visual Studio is Microsoft's Windows IDE, licensed either by subscription or as a one-time perpetual purchase, and Microsoft's Visual Studio subscription pricing sets the rates. Subscribers get Visual Studio 2026 at no extra cost, because a subscription includes releases published during its term. A perpetual license covers only the version bought, so a shop that purchased Visual Studio 2022 Professional outright is looking at a new license to target .NET 10 from the IDE.

There is a legitimate workaround for teams that only need to ship: the .NET 10 SDK builds net10.0 projects on the command line and in CI without any Visual Studio license at all. Developers can keep an older IDE for editing while the build system moves ahead. That is a stopgap rather than a plan, since debugging and project templates drift out of alignment, but it separates the November deadline from the license renewal.

What to do in the next ten weeks

1. Inventory every service by target framework, and separate the net8.0 and net9.0 projects from anything still on .NET Framework.
2. Retarget one low-risk service to net10.0 first and run its full test suite, so the library surprises arrive early.
3. Audit cookie-authenticated API endpoints against the ASP.NET Core 10 breaking-change list, especially anything a browser client calls with fetch.
4. Check whether any build agent or developer machine sits below Visual Studio 17.14, and price the Visual Studio 2026 licenses separately from the migration work.
5. Move remaining services in batches, keeping .NET 10 as the single target rather than staging through .NET 9.
6. Leave anything still on .NET Framework 4.8 out of this plan, because that is a re-platforming project rather than a retarget.

Point five deserves emphasis. There is no benefit in an intermediate hop now, since .NET 9 expires on the same day as .NET 8.

Teams sizing this work will recognize the pattern from TypeScript 7 is 10x faster. Can your project use it? — the compiler or runtime upgrade is cheap, and the ecosystem around it sets the real date. The same dynamic shows up in Spring Boot 4 and Jackson 3: the silent catch problem, where the framework moved and a serialization dependency decided the difficulty.

Should you move now or wait?

Move now if you run .NET 8 or .NET 9 in production and answer to any security or compliance process. Ten weeks is enough for a staged migration and nowhere near enough for a rushed one, and the deadline does not slip.

Wait only if a specific dependency has no .NET 10 build and its maintainer has published a date. In that case the honest options are a paid extended-support contract from a third party, or pinning that one service while the rest of the estate moves. Both are decisions to record, not defaults to drift into.

Ignore the deadline only for internal tools with no network exposure and no audit obligation. Even then, the upgrade gets more expensive the longer the gap grows, because the next LTS after .NET 10 will not accept a two-generation jump any more gracefully than this one.