.NET 8 End of Support Checklist: What to Do Before 10 November 2026

The short answer

.NET 8 and .NET 9 both reach end of support on 10 November 2026. Before then: list every .NET 8 and 9 runtime, image and cloud app; patch what stays; retarget the rest to .NET 10 LTS, supported until 14 November 2028; and decide in writing what covers anything left behind.

Nothing stops running on the day. Microsoft stops issuing security fixes, patch releases and support for both versions. This checklist is ordered so the discovery work comes first and the decisions come last. The how-to detail sits in our guides, linked at each step.

Dates to work from

Sources: Microsoft's .NET support policy and endoflife.date, both checked 28 October 2026. The dates are also on OSSeva's .NET 8 end-of-support page and the .NET 9 page. 10 November 2026 is a Tuesday, the November Patch Tuesday.

Phase 1: Find every .NET 8 and 9 workload

Step 1. List runtimes and SDKs on servers and build agents

Run these on each host. The output names every installed runtime, including Microsoft.AspNetCore.App and Microsoft.WindowsDesktop.App.

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

Any line starting 8.0 or 9.0 is on your list. Include CI agents, developer images and jump hosts, because a pipeline that builds on an old SDK keeps shipping old targets.

Step 2. Search source for target frameworks and SDK pins

grep -rlE "<TargetFrameworks?>[^<]*net(8|9)[.]0" --include="*.csproj" --include="*.props" --include="*.targets" .
grep -rn '"version"' --include="global.json" .

Check multi-targeted projects (the plural TargetFrameworks property), shared Directory.Build.props files and global.json pins. A global.json that pins an 8.0 SDK without a roll-forward policy will fail the build on a machine with only the 10.0 SDK. Microsoft documents the rollForward setting in its global.json reference.

Step 3. Find apps that carry their own runtime

Self-contained and single-file deployments bundle the runtime. Microsoft's deployment documentation says a self-contained app does not roll forward to the latest .NET security patch and that its runtime can only be upgraded by releasing a new version of the app. Patching the server fixes nothing for these.

grep -rnE -e "SelfContained>true" -e "--self-contained" -e "PublishSingleFile" --include="*.csproj" --include="*.yml" --include="*.yaml" --include="*.sh" --include="*.ps1" .

Step 4. Find container images

Search Dockerfiles for the 8.0 and 9.0 tags, check images you publish with dotnet publish -t:PublishContainer, and read DOTNET_VERSION from the images that are running. The commands are in .NET 8 Docker images after end of support.

grep -rnE "mcr[.]microsoft[.]com/dotnet/(sdk|aspnet|runtime|runtime-deps):[89][.]0" --include="Dockerfile*" .

Step 5. Check the cloud stack settings

Platform dates: Microsoft Learn and AWS documentation, checked 28 October 2026.

Step 6. Scan dependencies for packages that block the move

dotnet list package --vulnerable --include-transitive
dotnet list package --deprecated

From the .NET 10 SDK the same command is written dotnet package list. Look for NuGet packages that only target net8.0 or older, and for in-house libraries that other teams reference. Those decide the upgrade order.

Phase 2: Decide the order

Step 7. Sort every workload into one of three buckets

Step 8. Install the latest patch on everything that stays

Microsoft's policy says systems must have the latest patch update installed to qualify for support. For .NET 8 that is 8.0.33 and for .NET 9 it is 9.0.22 as of 25 October 2026. Do this before the date for workloads that move later, and rebuild self-contained apps so they pick up the patched runtime.

Phase 3: Upgrade

Step 9. Go straight to .NET 10

Do not stop at .NET 9. It is a Standard Term Support release and ends on the same day as .NET 8. .NET 10 is the current LTS release. .NET 11 is at its go-live release candidate stage and is a Standard Term Support release, so it is not the target for a deadline project. .NET LTS vs STS explains the support lengths.

Step 10. Retarget, fix and test

1. Install the .NET 10 SDK on a branch and update global.json.
2. Change TargetFramework to net10.0, update packages and rebuild.
3. Work through the breaking changes in the .NET 8 to .NET 10 upgrade guide.
4. Run the full test suite and a load test against production-like data.

Step 11. Rebuild container images on 10.0 tags

Move the build and runtime stages together. The multi-platform 10.0 tags resolve to Ubuntu rather than Debian, so test any image that installs OS packages. Pin by digest. Details are in the container image guide.

Step 12. Update the platform settings and redeploy

Set the .NET 10 stack on App Service, move in-process Functions apps to the isolated worker on .NET 10, and switch Lambda functions to the dotnet10 runtime or a 10.0 container image. Deploy to staging first, then production, and re-run steps 1 and 5 against the result to confirm nothing still reports 8.0 or 9.0.

Phase 4: Plan for what cannot move

Step 13. Choose a cover option and write it down

For each workload in the "cannot move" bucket, record the owner, the date it will move, the compensating controls, and who accepted the risk. Auditors reviewing PCI DSS, DORA or NIS2 scope ask for that record; see end-of-life software and PCI DSS and DORA and NIS2.

The cover options are:

• Accept the risk for a short, dated period with scanner exceptions and network controls around the workload.
• Isolate it. Remove internet exposure and tighten egress while the upgrade is finished.
• Keep .NET 8 or 9 patched by a third party. OSSeva ships patched .NET 8 and 9 runtimes after 10 November 2026: Windows installers and Linux Docker, apt, yum or binary delivery, signed with GPG and Sigstore, including patched SDK and ASP.NET Core Docker base images in Alpine and Debian variants. Critical CVEs are patched within 48 hours and High within 7 days (OSSeva's support SLA). Patched builds cover .NET (Core and 5 and later); .NET Framework is outside them. OSSeva for .NET is priced per application runtime environment. See .NET 8 extended support, OSSeva for .NET and the provider comparison.

Compare the paid options with the cost of finishing the upgrade using the upgrade vs extended support calculator.

What changes on 10 November 2026

One-page printable checklist

Print this section, or copy the table into your ticket tracker.

Frequently asked questions

When does .NET 8 support end?

10 November 2026. Microsoft's .NET support policy lists the same date for .NET 9, and 14 November 2028 for .NET 10.

Will my .NET 8 apps stop working on 10 November 2026?

No. End of support means Microsoft stops releasing security fixes and providing support. Installed runtimes, container images and NuGet packages keep working.

Do I need to upgrade to .NET 9 first?

No. .NET 9 reaches end of support on the same day as .NET 8, so it buys nothing. Upgrade from .NET 8 directly to .NET 10.

What do I need to do to stay supported until 10 November?

Microsoft's policy says you need the latest patch update installed. For .NET 8 that was 8.0.33 and for .NET 9 it was 9.0.22 on 25 October 2026.

Does this checklist cover .NET Framework?

No. .NET Framework has its own support policy. This page covers .NET 8 and .NET 9, the successors to .NET Core.

How can I keep .NET 8 patched past 10 November 2026 if I cannot upgrade in time?

Run a third-party patched build. OSSeva patches .NET 8 and 9 after Microsoft support ends, with Critical CVEs patched within 48 hours and High within 7 days, and ships signed runtimes and Docker base images. See .NET 8 extended support.