The end of life for .NET 8 and .NET 9 will be on November 10,2026. This means Microsoft ends its release of servicing updates and security patches for these frameworks. Also, it stops offering technical support for them. The long-term supported release is .NET 10, which will be supported until November 2028.

If one has applications using .NET 8 and .NET 9, the main concern is not whether applications will suddenly stop working. The main concern is how quickly a migration path will be developed to move them to a version which receives security updates. This guide covers issues such as when .NET 8 and 9 will stop receiving support; the meaning of end of life; what should be migrated first; and provides a step-by-step guide for the upgrade process.

Note: this deadline refers to modern .NET framework only. .NET Framework has a different lifecycle.

.NET Support Lifecycle: .NET 8 vs .NET 9 vs .NET 10

Support dates and status as of October 2026

Both older versions expire on the same day, so there is no benefit to using .NET 9 as a stepping stone. Anything you move to .NET 9 today would be out of support within weeks.

LTS vs STS in plain terms

Microsoft provides a duration of three years of costless support and patches for its LTS (long-term support) version and a period of two years for its STS (short-term support) version. .NET 8 (which was released in November 2023) represents the LTS release. .NET 9 (which was released in November 2024) represents the STS release and thereby its shorter counting will coincide with that of .NET 8. .NET 10, released in November 2025, will become the LTS version. Earlier articles stated the support period for STS versions of Microsoft is 18 months, but present information indicates that it was recently extended to 24 months.

What Actually Happens When .NET 8 or .NET 9 Support Ends

Security and servicing

After November 10, there will be no official fixes for vulnerabilities found in .NET 8 or .NET 9 runtime and libraries. The code has not changed with date, but the threats will keep emerging. A runtime that will not be patched will become riskier.

Dependencies, vendors and compliance

The impact is usually indirect. Library developers and vendors test against the supported targets, so eventually you may come across new packages or integrations that are not verified for .NET 8 or .NET 9. Security evaluations and customer questionnaires often ask whether the runtime you are using is supported and “no” can be a blocking factor. The tools also get affected: according to Microsoft, the upcoming servicing update for Visual Studio 2022 will declare .NET 8 and .NET 9 out of support.

What does not happen

Currently, applications continue running, and the installations are not getting removed. No kill switch will be turned on on November 11. The danger is growing risk, rather than sudden shutting down.

Should You Migrate to .NET 10?

In general, for most teams, the answer is affirmative, and the crucial issue revolves around sequence.

Migrate first: public-facing applications, anything with customer or regulatory data, and applications in ongoing development.

Analyze before deploying: applications with heavy reliance on third-party services or products, non-standard authentication middleware, older versions of EF Core libraries, and Windows-based applications. These are what can be resolved via a small audit beforehand.

Why is .NET 10 a good fit for enterprise applications? The reason for that is that this is a long-term support version and there are about three years ahead for the technology to be supported, so one migration now means no forced next migration shortly. You should not expect any great performance improvements though, since it is pretty workload-dependent, and most of the business applications do not change practically.

.NET 8 vs .NET 9 vs .NET 10: What Matters for Upgrade Decisions

The row that surprises people is the second one. You can retarget directly from .NET 8 to .NET 10, but breaking changes accumulate, so review both Microsoft's .NET 9 and .NET 10 lists.

Pre-Migration Readiness Checklist

This checklist is about what to verify before changing anything. The steps in the next section cover what to do.

Inventory: SDKs, runtimes and target frameworks

1. List installed SDKs and runtimes on build agents and servers: dotnet --list-sdks and dotnet --list-runtimes.
2. Check global.json and search every .csproj and Directory.Build.props for TargetFramework or TargetFrameworks.
3. Pass criteria: every project and host is accounted for, including forgotten console jobs and shared libraries.

Dependencies: NuGet, third-party libraries, EF Core and authentication

1. Run dotnet list package --outdated, --deprecated, --vulnerable and --include-transitive.
2. Flag packages with no stated .NET 10 support, your EF Core provider versions, and authentication libraries (cookies, JWT, identity).
3. Pass criteria: every blocker has an owner and a replacement or upgrade path.

Pipelines, containers and hosting

1. Check CI agent SDK versions, Dockerfile base images, and which runtimes your hosting platform offers. Note that Microsoft's default .NET images now use Ubuntu.
2. Pass criteria: a staging build runs on .NET 10 images.

Safety nets: tests and rollback

1. Measure automated test coverage on critical paths rather than chasing a global percentage.
2. Confirm you can redeploy the last known-good .NET 8 build, and rehearse it.
3. Pass criteria: a smoke-test suite you trust and a rollback you have actually practiced. If regression coverage is thin, consider automated regression testing before you start.

Step-by-Step: Migrating From .NET 8 or .NET 9 to .NET 10

You can move directly from .NET 8 or .NET 9 to .NET 10. First, separate three things that are often confused:

1. Installing the SDK puts the .NET 10 tooling on build machines.
2. Retargeting means changing a project's TargetFramework to net10.0.
3. Updating the deployment runtime means making sure servers and containers actually have .NET 10.

Retargeting without a runtime available at deployment is the classic failed first release.

1. Audit the application and dependencies

Use the checklist above. Rank applications by exposure and dependency depth, and start with a pilot that is low risk but representative.

2. Read the breaking changes before touching code

Review Microsoft's breaking-change pages for .NET 10, ASP.NET Core 10 and EF Core 10, plus the .NET 9 list if you are coming from .NET 8. Microsoft notes that the .NET 10 list is not exhaustive, so it is a starting point rather than a guarantee.

3. Prepare a migration branch and rollback strategy

Create a dedicated branch, tag the last known-good .NET 8 or 9 release, and make sure your deployment process can revert to it quickly.

4. Install the SDK and retarget

Install the .NET 10 SDK, confirm it with dotnet --list-sdks, and optionally pin the version you validated in global.json (replace the version with the one you tested):

Then retarget each project:

<PropertyGroup>

  <TargetFramework>net10.0</TargetFramework>

</PropertyGroup>

For shared libraries consumed by apps you cannot move yet, multi-target during the transition:

<TargetFrameworks>net8.0;net10.0</TargetFrameworks>

If you multi-target a project that uses EF Core migrations, the EF tools now require you to name the framework:

dotnet ef migrations add MyMigration --framework net10.0

Update CI to match. For GitHub Actions, for example, set dotnet-version: 10.0.x in actions/setup-dotnet, and update Dockerfile base images:

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

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime

5. Update packages

Bring Microsoft packages (Microsoft.*, EF Core, ASP.NET Core) up to the 10.x line to match the framework, then upgrade third-party packages. Rebuild, then re-run dotnet list package --vulnerable.

6. Address code and configuration incompatibilities

Fix compiler errors and obsolescence warnings first. Then deal with behavioral changes, which only show up at runtime. The next section lists the ones most likely to matter.

7. Test functionality, integrations, security and performance

Work in order: unit tests, integration tests (database, queues, external APIs), authentication flows, then a performance comparison against your .NET 8 baseline. Include security checks, such as how unauthenticated API calls behave.

8. Deploy through staging or a controlled rollout

Release to staging first, then use a canary, blue-green or percentage rollout depending on your platform. Keep the rollback path from step 3 ready.

9. Monitor production and resolve post-migration issues

Watch error rates, latency, memory, startup and shutdown behavior. Keep the rollback window open until the application has run through a full business cycle without regressions.

Common .NET 10 Migration Problems and How to Fix Them

Most of these are behavioral changes rather than compile errors. That is why testing matters more than the build going green.

Planning the Migration Across Several Applications

Prioritizing and sequencing

Rank applications by exposure (public-facing, data sensitivity), dependency depth and test readiness. Move shared libraries first, using multi-targeting, then the services that depend on them. To estimate effort, run one pilot application and use its real numbers. Effort tracks dependency count, test coverage and hosting complexity, so there is no honest universal timeline.

Migration decision checklist

1. Do we have a complete inventory of .NET 8 and .NET 9 applications?
2. Does every dependency blocker have an owner?
3. Have we rehearsed a rollback?
4. Does staging run on .NET 10 images?
5. Have critical vendors confirmed support?
6. Is there a monitoring plan for the first weeks after release?
7. Has a pilot application completed the full path?

When a .NET Migration Partner Makes Sense

This is often managed internally by many teams but outsourcing makes more sense when you have many applications and a quick timeframe. Third-party integrations that are complicated, not enough capacity on the inside, and important workloads in production also show when to go for help from the outside.

Avidclan Technologies has custom .NET development and migration services which include ASP.NET Core, Azure, microservices and Docker as well as testing solutions. If you want to engage extra help, you can hire dedicated .NET developers.