.NET 8 and 9 Support Ends November 10: Upgrade to .NET 10

.NET 8 LTS and .NET 9 STS reach end of support on the same Patch Tuesday​

Microsoft first announced the date on the .NET Blog on June 29, 2026. After that date, Microsoft will no longer provide servicing updates, security fixes, or technical support for these versions. InfoWorld, NT Compatible and several consultancies reported the date independently. Microsoft's official .NET and .NET Core support policy, last updated September 8, 2026, lists both versions with the same end-of-support date. Both are in the "Maintenance" phase.

Here is where each release stands, according to Microsoft's support policy table:

You might expect an LTS release and a short-term release to expire at different times. They line up because of a policy change. As Microsoft announced, STS releases now get 24 months of support instead of 18. That puts .NET 9 end of support on the same day: November 10, 2026. The current policy gives LTS releases three years of free support and patches and STS releases two. Microsoft says the two tracks differ only in how long they're supported, not in release quality. Since .NET Core 3.1, end-of-life dates fall on the Patch Tuesday nearest the anniversary. .NET 8's three-year window therefore closes on November 10 rather than the calendar anniversary.

There may be one more patch. November 10th is a Patch Tuesday release day. .NET 8 and .NET 9 may each receive one final update on that day if there is a known critical issue. Don't plan around it. It is a possibility, not a promise.

November 10 cuts off patches, not your apps​

End of support is a servicing event, not a kill switch. Microsoft defines it as the date after which it no longer provides fixes, updates or technical assistance for a version. Apps that target .NET 8 or .NET 9 will keep launching on November 11. As NT Compatible put it, "Your apps won't suddenly crash. They'll keep running."

The risk builds from there. Microsoft's releases documentation says versions that are out of support no longer receive the security updates that protect applications and data. The support policy strongly recommends against running out-of-support software. It also warns that doing so may put applications, application data and the computing environment at risk. For internet-facing ASP.NET Core services, that exposure starts with the first runtime vulnerability published after November 10.

The support clock has been running down for a while. The maintenance phase covers the final six months of any .NET release, and during it Microsoft ships security fixes only. Both .NET 8 and .NET 9 have been security-only since May 2026. Crash, performance or functional bugs found in that window were already out of scope for fixes.

One point of confusion is worth correcting. At least one widely shared community post said ".NET Framework" also reaches end of support on November 10. It doesn't. The date applies to modern .NET, which Microsoft's policy defines as the runtime, the SDK, ASP.NET Core and Entity Framework Core. .NET Framework runs on a separate clock: 4.8/4.8.1 live as long as the Windows they ship with, 4.6.2 ends January 12, 2027.

Why installing the .NET 10 runtime won't move your .NET 8 apps​

Many admins assume that installing a newer runtime automatically carries old apps forward. For major versions, it doesn't. Microsoft's documentation says major and minor .NET releases install side by side. An app built for a specific major.minor version keeps using that runtime even when a newer one is present. By default, an app targeting .NET 8 won't roll forward to a newer major version. Putting .NET 10 on a server leaves every .NET 8 app on that box running on .NET 8.

Patch versions work the other way. Within a major version, apps roll forward automatically to the latest installed patch. If 9.0.20 is installed, a .NET 9 app uses it. That's why Microsoft ties support eligibility to staying current. You're only supported if you've installed the latest released patch, and the major version number alone isn't enough.

How an app is deployed decides who does the patching:

• Framework-dependent apps use the shared runtime on the machine. On Windows, Microsoft Update can patch any supported .NET version automatically.
• Self-contained apps bundle their own runtime. Microsoft Update doesn't touch them, so the app's publisher is responsible for shipping runtime updates.
• Container images pin a runtime version in their base image. They only change when someone updates the FROM line and rebuilds.

After November 10, none of these routes delivers new .NET 8 or .NET 9 fixes. Self-contained apps are the easiest to miss in an inventory, because the runtime ships inside the application folder rather than appearing as an installed .NET component.

Developer workstations will see the change too. Starting with a future Visual Studio 2022 update, the older runtime components will be flagged as unsupported, though existing applications will continue to run without intervention. In comments on Microsoft's announcement, one developer pointed out that the Visual Studio Installer has an option to remove out-of-support components. That developer recalled it being on by default. If your builds depend on the .NET 8 or .NET 9 SDK being present in Visual Studio, check that setting before the next Visual Studio update.

The .NET 10 upgrade checklist from Microsoft's own guidance​

Microsoft's "Upgrade to a new .NET version" guide treats the move as five separate jobs: the development environment, source code, version pinning, CI, and hosting. InfoWorld sums up the minimum: apps can be upgraded to .NET 10 by changing the value of the TargetFramework property in a project file to net10.0. Development and hosting environments will need to be updated.

Update the toolchain and the project file​

1. Install the .NET 10 SDK. It includes the updated CLI, build system and runtime. Visual Studio installs new SDK versions itself, so for Visual Studio users, updating Visual Studio is enough.
2. Open each project file (.csproj, .vbproj or .fsproj) and change <TargetFramework> to net10.0. Multi-targeted projects work the same way through <TargetFrameworks>.
3. Build with the new SDK. Microsoft says the SDK's warnings and errors will point to any further changes needed. Projects that use workloads may also need dotnet workload restore.
4. Check for a global.json file. If the repository pins an SDK there, a pin such as 9.0.x will keep builds on the old SDK until you edit it. Microsoft's ASP.NET Core migration guide shows changing the version property to an installed .NET 10 SDK version, such as 10.0.100.

Microsoft's upgrade guide also notes that the GitHub Copilot modernization chat agent can make the target-framework edits automatically. Microsoft has deprecated the older .NET Upgrade Assistant and now points developers to that agent instead. Microsoft says the agent is included in Visual Studio 2026 and in Visual Studio 2022 17.14.16 or later.

Control what else changes with the SDK​

A new SDK also brings new analyzer rules and a new NuGet version. Microsoft's guide offers two ways to keep a framework upgrade from turning into an analyzer cleanup at the same time. Setting <AnalysisLevel>9.0</AnalysisLevel> enables only the analyzer rules that shipped with .NET 9, even when you build with the .NET 10 SDK. You can then deal with the new .NET 10 rules later. Teams that use packages.lock.json should know that a lock file doesn't protect the dependency graph from SDK changes. Microsoft recommends pinning the exact SDK in global.json with rollForward set to disable if restores must be reproducible.

Update packages, CI and hosting​

For ASP.NET Core apps moving from .NET 9, Microsoft's migration guide says to update every Microsoft.AspNetCore.*, Microsoft.EntityFrameworkCore.*, Microsoft.Extensions.* and System.Net.Http.Json package reference to version 10.0.0 or later. That instruction comes specifically from the ASP.NET Core 9-to-10 guide. Other project types should check their own dependencies.

Microsoft says CI pipelines can usually be updated by changing version values alone. Hosting takes more work:

• Servers that host framework-dependent apps need the .NET 10 runtime installed.
• Containers need their FROM statements updated. For example, an image built on mcr.microsoft.com/dotnet/aspnet:9.0 has to move to the 10.0 tag and be rebuilt.
• Azure App Service needs a configuration change to select the new runtime.

Where .NET 10 upgrades break: Blazor, breaking changes and vendor apps​

The upgrade is often a one-line edit, but not always. Microsoft publishes a list of .NET 10 breaking changes. It covers ASP.NET Core, containers, core libraries, cryptography, Entity Framework Core, networking, serialization, Windows Forms and WPF. Teams should read the sections that match their stack before assuming a clean build means a clean upgrade.

Blazor has the most concrete documented changes in Microsoft's ASP.NET Core 9-to-10 guide:

• Standalone Blazor WebAssembly apps no longer set their environment from the Blazor-Environment header or launchSettings.json. You now set it with the <WasmApplicationEnvironmentName> MSBuild property in the project file. Builds default to Development and publishes to Production.
• The blazor.boot.json file has been folded into dotnet.js. This matters for teams that ran integrity-check PowerShell scripts or renamed DLL file extensions. Microsoft says there's currently no documented replacement for either approach.
• The BlazorCacheBootResources MSBuild property no longer has any effect and should be removed. All client-side files are now fingerprinted and cached by the browser.
• Blazor Web Apps with Individual Accounts that set BlazorDisableThrowNavigationException to true need edits to IdentityRedirectManager.cs. You remove the InvalidOperationException from RedirectTo and the [DoesNotReturn] attributes.

Some .NET 8 and .NET 9 code isn't yours to upgrade. If you rely on a third-party application built on .NET 8 or .NET 9, contact your software vendor to confirm that a .NET 10-compatible version is available. Autodesk shows how far this reaches. The company told customers that many Autodesk products include components or dependencies that rely on Microsoft .NET technologies, and it has published .NET 10 update plans and beta builds for plug-in developers.

.NET 11 is not an escape hatch from the November 10 deadline​

Some teams are thinking about skipping .NET 10 and going straight to .NET 11. The timing rules that out for now. Microsoft's .NET Conf 2026 runs November 10–13 and marks the launch of .NET 11, so general availability lands on the same day .NET 8 and .NET 9 lose support. .NET 11 Release Candidate 1 shipped September 8, 2026. It carries a go-live license, which means Microsoft supports it in production, but that support for RC1 ends October 13, 2026. Running a release candidate in production means keeping up with each successive build.

The support window doesn't favor .NET 11 either. Odd-numbered releases are STS, with two years of support. On that basis, a November 2026 .NET 11 release would run out of support at roughly the same time as .NET 10 in November 2028. That's our estimate from Microsoft's published cadence, not a date Microsoft has announced. .NET 10 is already GA and on its twelfth patch, with support confirmed until November 14, 2028. It's the safer target.

What this means for you​

Anyone running production workloads on .NET 8 or .NET 9 should schedule upgrade and test work for October. Leave time for a staged rollout before November 10. Consultant Mitchel Sellers advises putting internet-facing systems, applications handling sensitive information, shared services, and systems with limited automated test coverage first. Internal tools with little exposure can come later, but they should still be on the list, because they'll stop getting fixes on the same day.

• Inventory every .NET 8 and .NET 9 dependency: project files, global.json pins, container base images, App Service settings, self-contained app folders and vendor products.
• Change TargetFramework to net10.0, build with the .NET 10 SDK, and fix what the compiler reports. Then review the .NET 10 breaking-changes sections that match your stack.
• Set the CheckSdkVulnerabilities MSBuild property to true in your projects. Once the resolved SDK is end of life, builds will emit warning NETSDK1239.
• Keep .NET 8 and .NET 9 hosts on the latest patches (8.0.31 and 9.0.20 as of September 8) until cutover, and install any final November 10 update.
• Ask vendors in writing when they'll ship .NET 10-compatible releases of any third-party software built on .NET 8 or .NET 9.
• Remove the .NET 8 and .NET 9 runtimes from machines that no longer use them. Microsoft recommends uninstalling out-of-support versions that aren't in use.

For most codebases, moving from .NET 8 or .NET 9 to .NET 10 is a known quantity: a target-framework edit, an SDK pin update, package bumps and a round of testing. The difficult part is finding every copy of the old runtime and fitting validation into the next seven weeks. Teams that finish before November 10 get two more years of supported .NET 10 servicing. Teams that miss it will be running unpatched runtimes while Microsoft launches .NET 11 at .NET Conf that same week.