Start a project

Guide · Modern .NET

.NET 8 and .NET 9 support ends on 10 November 2026.

Microsoft ends support for .NET 8 and .NET 9 on 10 November 2026: no more security updates, fixes or technical support for either, or for Entity Framework Core 8 and 9. Apps keep running. The supported destination is .NET 10, the long-term support release, supported until 14 November 2028; for most ASP.NET Core and worker services the move is a contained upgrade rather than a rewrite.

Ends
10 Nov 2026
Versions
.NET 8 (LTS), .NET 9 (STS)
Move to
.NET 10 LTS, to 14 Nov 2028
Same day
EF Core 8 and 9
Verified
7 Oct 2026
What ends
Security updates, fixes and technical support for .NET 8, .NET 9, ASP.NET Core 8 and 9, and EF Core 8 and 9.
When
, both versions on the same day.
Move to
.NET 10, the long-term support release, supported until 14 November 2028.
Who it affects
Teams running modern .NET: ASP.NET Core APIs and web apps, Blazor, worker services, and desktop apps on Windows Forms or WPF. .NET MAUI has its own dates.
First step
List every service with its target framework, SDK, container image and hosting, then upgrade one of them to .NET 10 this month.
Source
Microsoft’s .NET support policy, dates verified 7 October 2026.

Before you change anything. This guide is general information, not advice for your system. The dates and steps come from Microsoft’s published pages, checked on 7 October 2026, and Microsoft can change them, so confirm on the linked source before you plan around a date. Back up, test every change on a copy that isn’t in production, keep a way back, and follow your own change process. You follow these steps at your own risk (terms). SnowDriven isn’t affiliated with Microsoft (trademarks).

What ends, and what doesn’t

End of support is about patches and help from Microsoft. Nothing switches off.

From 10 November 2026, Microsoft ships no more security updates or fixes for .NET 8 or .NET 9 and its support teams no longer help with them. Apps built on either version keep running. What changes is that a vulnerability found in the runtime, ASP.NET Core or EF Core after that date stays open on every server and container still using them.

Both versions end the same day because Microsoft extended standard-term support from 18 to 24 months, starting with .NET 9. .NET 8 is a long-term support release with three years of support; .NET 9 is a standard-term release with two.

.NET 10 is the current long-term support release: released on 11 November 2025 and supported until 14 November 2028. EF Core 10 targets .NET 10 and is supported until 10 November 2028. Hosts follow the runtime: on Azure App Service an app on an out-of-support version keeps running, but without security patches or App Service support for that runtime.

Still running something on the original .NET Framework? That follows a different calendar: see .NET Framework 4.6.2 end of support. Some of the estate on PHP? See PHP 8.2 end of life.

Check what you run

Two questions: what’s installed where the app runs, and what each project is built for.

Installed on the machine

On each server or build agent, or inside a running container, list the runtimes and SDKs with Microsoft’s documented commands:

dotnet --list-runtimes
dotnet --list-sdks

Each runtime line names a shared framework and its version. Versions starting 8. or 9. are the ones that lose support:

Microsoft.AspNetCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

dotnet --info shows both, with the operating system.

Built for, in the repository

The target framework in each project file says which runtime the app needs. But the version is pinned in more places than that: the SDK, the packages, the container images, the pipeline and the host. Search each repository for all of them; each one changes as part of the upgrade.

The two can differ. A machine often lists several versions side by side, so installing .NET 10 doesn’t move an app: retargeting it does. Remove the old runtimes once nothing targets them.

Where the version is pinned
WhereLooks likeBecomes
Project files (.csproj)<TargetFramework>net8.0</TargetFramework> or net9.0, or several in <TargetFrameworks>net10.0
global.json"version": "8.0.xxx" or a 9.0 SDK, under "sdk"A 10.0 SDK, such as 10.0.100
Package referencesMicrosoft.AspNetCore.* and Microsoft.EntityFrameworkCore.* and Microsoft.Extensions.* at 8.0 or 9.010.0.0 or later
DockerfilesFROM mcr.microsoft.com/dotnet/aspnet:8.0 and the matching sdk:8.0 build stageaspnet:10.0 and sdk:10.0
CI pipelines and build agentsAn SDK install or build image pinned to 8.0 or 9.0The 10.0 SDK
HostingA runtime stack set to .NET 8 or .NET 9, for example in App Service or Azure Functions.NET 10

The upgrade to .NET 10

From .NET 8 or .NET 9 it’s usually a contained change, done one service at a time.

  1. Update the SDK and tools

    Install the .NET 10 SDK on developer machines and build agents and update global.json. Microsoft officially supports targeting net10.0 only in Visual Studio 18.0 (Visual Studio 2026) and later, so plan the move off Visual Studio 2022 too.

  2. Retarget

    Set each project’s TargetFramework to net10.0. The default C# version follows the target: net10.0 brings C# 14, which is only supported on .NET 10 and later.

  3. Update packages, EF Core included

    Move every Microsoft.AspNetCore.*, Microsoft.EntityFrameworkCore.* and Microsoft.Extensions.* reference to 10.0, then third-party packages to releases that support .NET 10.

  4. Review the breaking changes

    Microsoft groups them by area. From .NET 8, read both lists: .NET 9 and .NET 10, plus ASP.NET Core 10 and the EF Core lists. We read all six for web apps and workers and sorted them by how likely each is to hit: .NET 8 to .NET 10 breaking changes.

  5. Update images and hosting

    Move Dockerfiles to the 10.0 sdk and aspnet images and CI to the 10.0 SDK, and set the hosting runtime to .NET 10 before the first deployment.

  6. Test, then deploy

    Run the test suite, then the workflows the business depends on, on a staging copy with production-like data. Back up the production database before the first migration runs. Deploy through the normal pipeline, with the previous build ready to roll back to.

Areas worth reading closely in the lists

  • ASP.NET Core 10: WebHostBuilder, IWebHost, WebHost and Razor runtime compilation are obsolete; cookie login redirects are disabled for known API endpoints.
  • Serialization (.NET 9): the built-in BinaryFormatter always throws.
  • EF Core 9: applying migrations throws when the model has pending changes, or when it runs inside an explicit transaction.
  • SDK and NuGet (.NET 10): restore now audits transitive packages for known vulnerabilities.
  • Containers (.NET 10): default image tags are based on Ubuntu, and no Debian images ship.
  • Desktop: Windows Forms and WPF each have their own entries, mostly obsoletions and changed defaults.

What tends to bite

The code change is often the small part. These are what turn a day’s work into a week.

Which path fits

A quick way to place each service.

IfThen
An ASP.NET Core API, web app or worker service on .NET 8Retarget to net10.0 directly; there’s no need to stop at .NET 9. Read the .NET 9 and .NET 10 breaking-change lists, since both releases apply.
Already on .NET 9The smallest step: one release of breaking changes to read. Update the SDK, retarget, update packages and test.
Azure Functions on the in-process modelThe in-process model’s support ends the same day and it doesn’t run .NET 10. Move to the isolated worker model as part of the upgrade.
A .NET MAUI appMAUI follows its own policy: MAUI 9 support already ended on 12 May 2026. Move to MAUI 10, supported until 11 May 2027, and plan the next move early.
A package you depend on has no .NET 10-compatible releaseCheck whether the current version runs on .NET 10 anyway, then look for a maintained alternative. Don’t let one library hold every service on an unsupported runtime.
Some of it still runs on .NET FrameworkDifferent timeline. Of the 4.x versions, only .NET Framework 4.6.2 has a fixed end date, 12 January 2027; see the 4.6.2 guide.

The weeks to 10 November

Start with the list, prove the path on one service, then repeat it.

  1. Week 1

    Take an inventory

    For every service: its target framework, SDK, packages, container image, CI pipeline and where it’s hosted. Flag in-process Azure Functions, MAUI apps and anything shared between services.

  2. Week 2

    Upgrade one service

    Pick a representative one, not the easiest. Take it through every step to production, and write down what broke and how it was fixed: that list is the playbook for the rest.

  3. Weeks 3–4

    Roll out

    Upgrade the remaining services with the playbook, shared libraries first. Update images and hosting with each release, so nothing is left half-moved.

  4. Week 5

    Clean up before the date

    Remove the 8.0 and 9.0 SDKs, images and runtime stacks from build agents and hosting once nothing on that machine or pipeline still uses them, so nothing drifts back. Note anything still pending, with an owner and a date.

How we can help

If the inventory turns up more than you can move by 10 November, or you’d like a second pair of eyes on the plan.

Scoped and quoted on its own

Modernization audit

The code, dependencies, data, hosting and releases reviewed, the risks ranked in a written report, and a step-by-step plan. Nothing beyond the audit is committed until you decide to go further.

Start with an audit How a modernization runs See a sample report

No email needed

Modernization readiness check

Ten yes-or-no questions about the system, including whether it runs on a version that no longer gets updates, and the first step we’d suggest.

Take the readiness check See the runway on every runtime

Questions about .NET 8 and 9 end of support

Will our apps stop working on 10 November 2026?

No. Apps built on .NET 8 or .NET 9 keep running. After that date Microsoft ships no more security updates or fixes for them and gives no technical support, so any vulnerability found later stays open.

Why does .NET 9 end on the same day as .NET 8?

Microsoft extended standard-term support releases from 18 to 24 months, starting with .NET 9. .NET 9 was released in November 2024, so its 24 months end on 10 November 2026, the same day as .NET 8’s three years of long-term support.

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

Yes. Change the target framework to net10.0, update the SDK and packages, and review the breaking changes Microsoft lists for both .NET 9 and .NET 10, since both releases apply to an app moving from .NET 8.

Do we have to upgrade Entity Framework Core as well?

Yes. EF Core 8 and EF Core 9 are supported until 10 November 2026, like the runtimes. EF Core 10 targets .NET 10 and is supported until 10 November 2028. EF Core 9 changed how migrations are applied, so test migrations against a copy of the database.

How long is .NET 10 supported?

.NET 10 is a long-term support release: released on 11 November 2025 and supported until 14 November 2028. Long-term support releases get three years, so the next move is part of the plan.

Sources · support dates verified 7 October 2026

Part of SnowDriven Research: see this date in the deadline table beside every other date we track, and how we verify them.

General information, checked on 7 October 2026. Confirm dates with the vendor; follow at your own risk. Terms.

Start a project

On .NET 8 or 9? Let’s plan the move.

Tell us what you run and where it’s hosted. We reply within one business day, with questions or a time to talk.

Start a projectRequest a scoping call

Pittsburgh, PA · Since 2015 · First step: a 30-minute call