.NET End of Life —
.NET 8 & 9 both EOL November 10, 2026
Quick answer: .NET 8 (LTS) and .NET 9 (STS) both reach end of life on November 10, 2026 — the same day. .NET 6, 7, and everything before are already EOL. The only version with runway past 2026 is .NET 10 (LTS), supported until November 13, 2028. If you're on .NET 8 thinking "I'm on LTS, I'm fine," note the date: you have until November 2026, not longer.
Complete .NET end-of-life schedule
Dates below are for modern .NET (formerly .NET Core), sourced from Microsoft's official support policy and the open endoflife.date dataset.
| Version | Latest | End of Life | Status |
|---|---|---|---|
| 10 LTS | 10.0.8 | Nov 13, 2028 | Supported |
| 9 (STS) | 9.0.16 | Nov 10, 2026 | Approaching |
| 8 LTS | 8.0.27 | Nov 10, 2026 | Approaching |
| 7 (STS) | 7.0.20 | May 14, 2024 | EOL |
| 6 LTS | 6.0.36 | Nov 12, 2024 | EOL |
| 5 | 5.0.17 | May 10, 2022 | EOL |
| 3.1 LTS | 3.1.32 | Dec 13, 2022 | EOL |
| 3.0 | 3.0.3 | Mar 3, 2020 | EOL |
| 2.1 LTS | 2.1.30 | Aug 21, 2021 | EOL |
For the full version history including the oldest .NET Core releases and live EOL Risk Scores™, see the .NET product page, regenerated at every deploy.
LTS vs STS: how the .NET cycle works
Microsoft ships a new major .NET version every November on a strict, predictable cadence — and alternates two support tracks:
- LTS (Long-Term Support) — even-numbered releases (6, 8, 10). Supported 3 years. These are what production should target.
- STS (Standard-Term Support) — odd-numbered releases (7, 9). Supported only 18 months. Meant for teams that want the newest features and can upgrade quickly, not for long-lived systems.
The quirk that catches teams: because STS lasts 18 months and a new LTS arrives a year after, an STS release and the LTS before it can expire close together — which is exactly what happens with .NET 8 (LTS) and .NET 9 (STS) sharing a November 10, 2026 EOL.
Migrating to .NET 10
.NET's high backward compatibility makes major-version upgrades far less painful than the old .NET Framework era. The typical path:
- Update the target framework moniker — change
<TargetFramework>net8.0</TargetFramework>tonet10.0in your project files. - Update NuGet packages — bump dependencies to their .NET 10-compatible versions; most popular libraries ship them on day one.
- Review breaking changes — Microsoft publishes a per-version breaking-changes list; most apps hit few or none.
- Update CI and base images — bump your
mcr.microsoft.com/dotnetDocker tags and pipeline SDK versions to 10.0. - Run your test suite — if it passes on .NET 10 in CI, production typically follows cleanly.
Skipping from .NET 6 or 7 straight to 10 is supported and usually the right move — there's no value in stopping at 8, which is itself only months from EOL.
Why an EOL .NET runtime is a real risk
After EOL, Microsoft stops shipping security patches for that .NET version. New CVEs disclosed against the runtime — and .NET processes HTTP requests, deserializes untrusted data, and runs in internet-facing services — never get fixed for your version. Your vulnerability scanner often won't flag it either, because it checks CVE version ranges that don't list the EOL build. That's the CVE blind spot, and it's why an unpatched runtime is among the higher-weighted factors in the EOL Risk Score™. For regulated teams, an EOL runtime is also a standard audit finding under SOC 2, PCI DSS, and ISO 27001.