.NET 8 support ends on 10 November 2026. Move to .NET 10 before the patches stop

In brief

Microsoft's support for .NET 8 ends on Tuesday 10 November 2026. .NET 9 ends on the same day. After that date Microsoft will no longer ship security fixes, servicing updates or technical support for either version.

Nothing switches off. Applications built on .NET 8 keep running exactly as they did the day before. What changes is that every vulnerability found in the runtime, ASP.NET Core or Entity Framework Core after that date stays open in those apps.

The supported destination is .NET 10, a long-term support (LTS) release that Microsoft will patch until November 2028. For most codebases the upgrade starts with a one-line change to the project file. The real work is in testing, dependencies, build pipelines and hosting, and in finding the .NET 8 workloads nobody remembers owning.

What ends on 10 November

.NET 8 shipped on 14 November 2023 as an LTS release, which Microsoft supports for three years. Under the .NET support policy, end-of-support dates fall on Patch Tuesday, the second Tuesday of the month, so the three years close on 10 November 2026 rather than on the anniversary.

.NET 8 has been in its "maintenance" phase for the last six months. During maintenance Microsoft fixes security vulnerabilities only. The latest patch Microsoft lists is 8.0.33, released on 25 October 2026. The .NET team says 10 November itself may bring one final update for .NET 8 and .NET 9, but only if there is a known critical issue.

From that point:

• Security patches stop. No new runtime, ASP.NET Core or EF Core fixes will be released for .NET 8. These components share the .NET lifecycle, so they all lose support together.
• Technical support stops. Microsoft support will no longer take cases for .NET 8 or .NET 9 applications.
• Tooling marks it as out of support. The .NET team says a future Visual Studio 2022 servicing update will flag the .NET 8 and .NET 9 components as out of support. Visual Studio offers a "remove out of support components" option; that option can remove components on update unless you opt out, so do not assume existing installs stay untouched.

.NET 9 deserves a mention because many teams treat it as the newer, safer choice. It is a standard-term support (STS) release. Microsoft extended STS support from 18 to 24 months, which happens to put .NET 9's end date on the same day as .NET 8's. Moving from .NET 8 to .NET 9 now buys nothing.

What still runs, and what the risk is

Microsoft is explicit that .NET 8 applications will continue to run after 10 November. There is no kill switch, no licence check and no forced upgrade.

The risk is cumulative rather than immediate. The policy page warns that using out-of-support versions "may put your applications, application data, and computing environment at risk". In practice:

• Internet-facing services are the priority. An ASP.NET Core 8 API or web app exposed to the public will be the first place an unpatched runtime vulnerability is exploited.
• Compliance clocks start. Many security frameworks and customer contracts require supported software. An auditor will ask about any production workload on an end-of-life runtime.
• Self-contained apps are already on their own. On Windows, Microsoft Update can patch framework-dependent apps. Self-contained deployments carry their own copy of the runtime and have always needed to be rebuilt to pick up fixes. After 10 November there is nothing more to rebuild with.

ByteNib's reading is that the date matters most for organisations with many small services, internal tools and vendor-supplied apps. A single flagship application usually has an owner and an upgrade ticket. The long tail rarely does.

The upgrade path: .NET 10 LTS

.NET 10 was released on 11 November 2025 and is Microsoft's current LTS release. The support policy lists its end of support as 14 November 2028, and its latest patch as 10.0.14 (25 October 2026). Microsoft's lifecycle page shows the same window as 11/15/2028 6:59:59 AM Pacific Time, which is 14 November 2028 23:00 UTC; treat 14 November as the calendar end date. Some earlier Microsoft posts give 10 November 2028; all of them still point to November 2028.

Microsoft's own recommendation is .NET 10, not .NET 11. .NET 11 is at release-candidate stage (RC3 on 25 October 2026) and, as an odd-numbered release, will be an STS release with a two-year window. For most organisations moving off .NET 8, an LTS-to-LTS jump to .NET 10 keeps the upgrade cycle at roughly once every two to three years.

Practical migration steps

Microsoft's upgrade guidance says the only required code change is the target framework. Everything else is verification. A workable sequence:

1. Install the .NET 10 SDK on developer machines and build agents. Visual Studio users get it with a current Visual Studio release.
2. Retarget each project. In every .csproj, .vbproj or .fsproj, change <TargetFramework>net8.0</TargetFramework> to net10.0, and update TargetFrameworks where projects multi-target. Microsoft points to GitHub Copilot's modernisation agent and the .NET Upgrade Assistant as tools that can help.
3. Build and read the warnings. The SDK reports what else needs changing. Run dotnet workload restore if you use workloads such as .NET MAUI.
4. Work through the breaking changes. Microsoft's ".NET 10 breaking changes" list is long, and it is not cumulative: coming from .NET 8, read the .NET 9 list as well. Items worth checking early include default .NET container tags now using Ubuntu rather than Debian (Azure Linux remains an explicit tag, not the default), BackgroundService running all of ExecuteAsync as a task, dotnet restore auditing transitive packages, and a PackageReference without a version now raising an error. ASP.NET Core and EF Core have their own lists.
5. Update packages. Move Microsoft.* and third-party NuGet packages to versions that support .NET 10. Central package management makes this one change per package rather than one per project.
6. Pin the toolchain deliberately. Use global.json to choose the SDK version and AnalysisLevel to control when new analyser rules apply, so the upgrade does not also change your build behaviour without notice.
7. Update CI and hosting. Change SDK versions in pipelines, FROM lines in Dockerfiles (for example mcr.microsoft.com/dotnet/aspnet:10.0), and the runtime setting in services such as Azure App Service. Install the .NET 10 runtime on any servers that host framework-dependent apps.
8. Test, then remove .NET 8. Run the full test suite and a production-like soak test. Once an app is live on .NET 10, uninstall the .NET 8 runtime where nothing else needs it, as Microsoft recommends.

For a team that has kept dependencies current, steps 2 to 5 can take days per application. Teams with older packages, custom MSBuild logic or heavy use of reflection and interop should expect longer.

How to check which apps are affected

Start with an inventory, not with the code. Three views help:

• Source code. Search repositories for net8.0 and net9.0 in project files, and for aspnet:8.0, runtime:8.0 and sdk:8.0 in Dockerfiles and pipeline definitions. This finds what you build.
• Machines. dotnet --list-runtimes shows installed runtimes (Microsoft.NETCore.App, Microsoft.AspNetCore.App, Microsoft.WindowsDesktop.App), and dotnet --list-sdks shows SDKs. dotnet --info adds the operating system details. If dotnet is not on the path, check the default install folders, such as C:\Program Files\dotnet\shared on Windows. This finds what you run, including software you did not build.
• Containers and cloud services. Scan image registries for .NET 8 base images, and check the runtime setting on platform-as-a-service apps and serverless functions.

Then sort the list. Internet-facing and regulated workloads first, internal tools next, and anything decommissioned can simply have the runtime removed. For vendor software, the .NET team's advice is to ask the vendor for a version built on .NET 10. Record the answer and the date, because "the vendor is working on it" is a risk you are accepting, not a plan.

A runtime that is installed is not necessarily one that is used. Machines often carry .NET 8 because an SDK or tool installed it. Removing it where nothing depends on it is the cheapest remediation available.

What IT leads should decide this week

Five days is not enough to upgrade an estate, so the useful decisions are about risk ownership:

• Name an owner for every .NET 8 and .NET 9 workload on the inventory, with a target date for .NET 10.
• Decide which exposed services need compensating controls, such as a web application firewall, tighter network access or extra monitoring, until they are upgraded.
• Record formal risk acceptances for anything that will still be on .NET 8 at the end of the year, so the exposure is visible rather than assumed.
• Plan the next cycle now. .NET 10 support ends in November 2028. Putting that date on the roadmap today avoids repeating this scramble.

Sources and scope

End-of-support calendar dates are from the .NET and .NET Core support policy (last updated 25 October 2026), which lists .NET 8 and .NET 9 ending on 10 November 2026 and .NET 10 on 14 November 2028. The .NET and .NET Core lifecycle page shows those windows in Pacific Time (for .NET 10, 11/15/2028 6:59:59 AM PT, which is 14 November 2028 23:00 UTC), so 14 November is the authoritative calendar date. Latest patch versions (8.0.33, 9.0.22, 10.0.14 on 25 October 2026) and the .NET 11 RC3 go-live entry (25 October 2026) are from that same support-policy page, not from the lifecycle page. What ends, what keeps running and the Visual Studio changes are from the .NET team's post ".NET 8 and .NET 9 will reach End of Support on November 10, 2026" (29 June 2026). The .NET 10 support window is also stated in Announcing .NET 10, which gives 10 November 2028; the policy page's 14 November 2028 figure is preferred. Upgrade steps follow Microsoft Learn's Upgrade to a new .NET version, Breaking changes in .NET 10 (including Default .NET container tags now use Ubuntu) and Check installed .NET versions. All were checked on 5 November 2026. Effort estimates, the prioritisation and the decisions for IT leads are ByteNib editorial analysis.

Drafted with AI assistance and reviewed by the editor before publication.

Cover illustration: AI-generated illustration: ByteNib

Continue exploring: Cloud & DevOps analysis, the related implementation tutorial, and the structured learning path.