.NET 8 and .NET 9 Are Out of Support: How to Move to .NET 10

.NET 8 and .NET 9 both reached end of support on November 10, 2026. Microsoft ships no more patches for either one, security fixes included, so move to .NET 10, the current LTS release, supported until November 14, 2028.

What ended on November 10, 2026

Microsoft's support policy lists the same end date for .NET 8 (LTS) and .NET 9 (STS): November 10, 2026. .NET 9 was due to end on May 12, 2026, but Microsoft moved STS releases from 18 to 24 months of support, starting with .NET 9 (.NET blog). That's why both versions went out on the same day.

From the .NET support policy, as of Nov 4, 2026

Here's what end of support means, from Microsoft's announcement: your apps keep running, but there are no more servicing updates, no security fixes and no technical support. November 10 was a Patch Tuesday, the last day either version could get an update. Any vulnerability found from now on stays open on 8 and 9.

This touches a lot of code. About 1.1 million project files on public GitHub still target net8.0 (GitHub's code search count, November 2, 2026, approximate, forks and docs included).

Where the version hides in your repo

Changing one project file isn't enough. The version is usually pinned in several places, and the one you miss either breaks the build or keeps shipping the old runtime. Check all of these:

Where .NET 8 and .NET 9 are pinned, and what to change

To find them, run these from the repository root, then open every global.json:

git grep -nE "net[89]\.0|dotnet[89]" git grep -nE "dotnet/[a-z-]+:[89]\.0" git grep -n "dotnet-version" 

Lambda keeps its own dates. AWS deprecated the dotnet8 runtime on November 10, 2026, blocks creating functions on it from July 29, 2027 and blocks updating them from August 31, 2027 (AWS Lambda runtimes).

How to move to .NET 10

Go straight from 8 to 10. You don't need to stop at 9, which ended the same day anyway. Microsoft's upgrade guide covers the steps below.

1. Install the .NET 10 SDK and update global.json. If it still pins an 8.0 SDK, the build either keeps using that SDK or fails to find one. With rollForward set to latestFeature, the pin stays inside that major version.
2. Change TargetFramework to net10.0 in every project, test projects included, and in Directory.Build.props if you set it there.
3. Move packages to the matching major. Set every Microsoft.AspNetCore.*, Microsoft.EntityFrameworkCore.*, Microsoft.Extensions.* and System.Net.Http.Json reference to 10.0.0 or later (ASP.NET Core migration guide). With central package management, they're all in Directory.Packages.props. EF Core 10 needs the .NET 10 runtime and won't run on earlier versions (EF Core docs), so EF Core and the target framework move together. Update your EF Core database provider to its EF Core 10 release too.
4. Update the Docker images to sdk:10.0 and aspnet:10.0. The default .NET 10 tags are Ubuntu 24.04, not Debian, and Microsoft doesn't ship Debian images for .NET 10 (Microsoft Learn). If your Dockerfile installs packages with apt or uses a Debian tag such as 8.0-bookworm-slim, test it on the new base.
5. Update CI. In actions/setup-dotnet, set dotnet-version to '10.0.x', or point global-json-file at your global.json so CI and your laptop use the same SDK.
6. Update hosting. On Azure App Service for Linux, change linuxFxVersion (App Service docs). On Lambda, change Runtime to dotnet10. On your own servers, install the .NET 10 runtime before you deploy.
7. Build, run the full test suite, then deploy to staging before production. The SDK reports what needs fixing in code as warnings and errors. Behavior changes only show up in tests.

The edits themselves are small. A project file:

<PropertyGroup> <TargetFramework>net10.0</TargetFramework> </PropertyGroup> 

A multi-stage Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build FROM mcr.microsoft.com/dotnet/aspnet:10.0 

A GitHub Actions step:

- uses: actions/setup-dotnet@v6 with: dotnet-version: '10.0.x' 

Breaking changes to check

Read Microsoft's list of breaking changes in .NET 10, plus the separate pages for ASP.NET Core 10 and EF Core 10. Coming from .NET 8, read the .NET 9 list too, since you're skipping it. These are the ones most likely to show up in a typical web app or worker:

• Restore audits transitive packages. Projects on .NET 10 now get vulnerability warnings for indirect dependencies too. If you treat warnings as errors, restore can fail. Upgrade the package that pulls the vulnerable one in, or add the vulnerable one as a direct reference at a fixed version.
• System.Linq.AsyncEnumerable is built in. If you reference the community System.Linq.Async package, remove it or move to its 7.0.0 release, or you may get ambiguous call errors.
• BackgroundService runs all of ExecuteAsync as a Task. Code before the first await no longer blocks other services from starting. If you relied on that ordering, move the work to StartAsync or the constructor.
• Default container tags use Ubuntu, as above. Also check any scripts that assume Debian package names.

If you haven't moved yet

Nothing stopped working on November 11. The risk is that the next security fix for .NET won't be released for 8 or 9, and you'll be running code with a known hole. Here's how to keep that window short:

1. Install the last 8.0 or 9.0 patch Microsoft shipped. Rebuild your images so they pick it up.
2. Move internet-facing services first. Internal jobs with no public input can follow.
3. Write down every service still on 8 or 9, who owns its move, and a target date. Review that list every week until it's empty.
4. On Lambda, dotnet8 functions keep running, and you can still update them until August 31, 2027. AWS may stop applying security patches after deprecation, though (AWS).
5. On App Service, an outdated runtime is hidden from the portal but apps on it keep running, and the subscription owner gets an email before a runtime is removed from the platform (App Service docs).

Microsoft's announcement doesn't mention any paid extension for .NET 8 or 9, so plan as if the date is final.

Where Since.dev fits

Since.dev tracks end-of-life dates like this one from the publisher's schedule. For a repository you scan or connect, it finds the exact file and line that pins .NET 8 or 9, with the days left and the version to move to.

• Scan any public GitHub repo, no sign-in.
• See every .NET date on the .NET calendar.
• Your coding agent can ask check_code over MCP with a manifest such as a .csproj or global.json, or with the surface runtime:dotnet@8.0.
• For public repositories on any plan, and private ones on Team and up, it opens a fix pull request for supported cases, ready for review. Nothing merges or deploys.

Questions

When does .NET 8 support end?

It ended on November 10, 2026, the same day as .NET 9. Microsoft now provides no servicing updates, security fixes or technical support for either version.

Will my .NET 8 app stop working after November 10, 2026?

No. It keeps running. It just stops getting patches, so any vulnerability found after that date stays open until you move to .NET 10.

Should I move to .NET 9 or .NET 10?

.NET 10. .NET 9 ended support on the same day as .NET 8. .NET 10 is an LTS release, supported until November 14, 2028.

Can I go straight from .NET 8 to .NET 10?

Yes. Change the target framework to net10.0 and update the SDK, packages, images and CI. Read the breaking change lists for both .NET 9 and .NET 10, since you skip a version.

Where did the last .NET version pin hide in your repo? Tell me in the comments.

First published on since.dev.