.NET 8 end of life is November 10, 2026. That is about five weeks from today, and it lands on the same day as .NET 9, so teams that jumped to the newer release to buy time bought none. After that date Microsoft ships no more security patches for either version, and the only supported long-term target is .NET 10.
The deadline surprised a lot of people for one reason. .NET 9 was originally due to end in May 2026, but in September 2025 Microsoft extended STS releases from 18 to 24 months. That moved .NET 9 onto the exact same date as .NET 8. Two versions, one cliff.
Key Takeaways
- .NET 8 and .NET 9 both reach end of support on November 10, 2026, per the official .NET support policy.
- The target is .NET 10 LTS, released November 11, 2025 and supported until November 14, 2028.
- AWS Lambda deprecates the `dotnet8` runtime on the same day, though existing functions keep running for months after.
- A single well-tested ASP.NET Core API moves in about a week; a handful of services with EF Core takes two to four engineer-weeks. The long tail is tests, containers, and third-party packages.
The .NET 8 End of Life Dates You Actually Need
.NET has no separate "active" and "security" phases. Each version gets full patches until its end date, then nothing. Here is the table, straight from Microsoft's policy page and the AWS Lambda runtimes page:
| Version | Type | Released | End of support | Lambda runtime deprecation |
|---|---|---|---|---|
| .NET 6 | LTS | Nov 8, 2021 | Nov 12, 2024 | Dec 20, 2024 |
| .NET 8 | LTS | Nov 14, 2023 | Nov 10, 2026 | Nov 10, 2026 |
| .NET 9 | STS | Nov 12, 2024 | Nov 10, 2026 | Nov 10, 2026 (container only) |
| .NET 10 | LTS | Nov 11, 2025 | Nov 14, 2028 | Nov 14, 2028 |
On Lambda, deprecation does not mean your functions stop. For `dotnet8`, creating new functions is blocked from July 29, 2027 and updating existing ones from August 31, 2027. That is a grace period, and it is also a trap: a team that cannot deploy a hotfix in September 2027 has an outage waiting to happen.
If you are still on .NET 6, you have been unpatched since November 2024. Skip 8 entirely and go straight to 10.
What Breaks When You Move to .NET 10
Most of the jump is a target-framework change and a package bump. The parts that bite are listed on Microsoft's .NET 10 breaking changes page. The ones I would check first:
- Container base images. "Default .NET images use Ubuntu." If your Dockerfile assumed Debian packages or paths, the build will tell you quickly. Your security scanner baseline will also change.
- OpenSSL 1.1.1 or later is required on Unix. Old custom base images fail here.
- BackgroundService runs all of ExecuteAsync as a Task. Worker services that did synchronous setup at the top of `ExecuteAsync` can change startup order.
- Null values preserved in configuration. Code that treated a missing value and an explicit null the same way may now take a different branch.
- System.Text.Json checks for property name conflicts. If a property collides with a metadata name like `$type`, `$id`, `$ref` or your custom type discriminator, serialization now throws `InvalidOperationException` up front instead of emitting duplicate keys. Polymorphic DTOs are where this shows up.
- SDK changes. `dotnet new sln` defaults to the SLNX format, and `dotnet restore` audits transitive packages, so CI starts warning about vulnerable dependencies you never knew you had (and fails, if you treat warnings as errors).
ASP.NET Core 10 and EF Core 10 each have their own breaking-change pages. If you use EF Core heavily, read that one before estimating.
How Long the .NET 8 Upgrade Takes
The honest answer depends less on lines of code and more on three things: test coverage, how many NuGet packages are pinned to old majors, and whether anyone remembers why the Dockerfile looks the way it does.
A rough sizing I use:
| Codebase shape | Typical effort |
|---|---|
| Single ASP.NET Core API, good tests, few packages | 3 to 5 engineer-days |
| 3 to 6 services, shared libraries, EF Core | 2 to 4 engineer-weeks |
| Monolith with Windows-only dependencies or old .NET Framework pieces | A separate project, not an upgrade |
That last row matters. If part of your system is still on .NET Framework 4.x, you are looking at a port, and the guide on how to hire developers to modernize a legacy app is the better starting point.
A Concrete Version
Say you run a B2B SaaS with four ASP.NET Core 8 services, one worker service, EF Core against SQL Server, and two Lambda functions on `dotnet8`. About 120,000 lines of C#, around 55% test coverage.
The plan, in engineer-days:
- Retarget all projects to `net10.0`, bump packages, fix compile errors: 4 days.
- Work through EF Core 10 and System.Text.Json changes, fix failing tests: 5 days.
- Rebuild containers on the new Ubuntu base images, update the scanner baseline: 2 days.
- Move the two Lambdas to `dotnet10`: 1 day.
- Staging soak, load test, staged production rollout: 3 days.
Total: 15 engineer-days. With one engineer that is three calendar weeks, which lands before November 10 only if it starts this week and nothing else interrupts it. With two engineers splitting the services, the build work drops to about six days, and the soak and rollout still take their three.
That math is the real reason companies call us for EOL work. The team knows how to do it. Nobody has 15 spare days while the roadmap is full. A senior engineer from a vetted shortlist who has run framework upgrades before can carry the mechanical work while your team reviews.
The Honest Counterpoint
Missing November 10 by a few weeks is not a disaster for most teams. An internal admin tool behind SSO with no public surface carries little real risk on an unpatched runtime for a month. A public API that parses untrusted JSON is different.
And sometimes the right move is to wait for the right moment instead of rushing. If you are already planning to split or rewrite a service in Q1, upgrading it now is wasted work; patch the risky edges and fold the upgrade into the rewrite. My post on whether to rewrite or refactor your app covers that call. What I would not do is assume "we'll get to it" and let a year pass. PHP 8.2 teams face the same choice in December. Unpatched runtimes compound into technical debt with a security bill attached.
Frequently Asked Questions
What is the .NET 8 end of life date?
November 10, 2026. Microsoft's support policy lists the same date for .NET 9.
Should I upgrade from .NET 8 to .NET 9 or .NET 10?
.NET 10. .NET 9 ends on the same day as .NET 8, so it buys you nothing. .NET 10 is LTS and supported until November 14, 2028.
Does .NET 8 end of life affect AWS Lambda functions?
Yes. AWS deprecates the `dotnet8` runtime on November 10, 2026. Existing functions keep running, but creating new ones is blocked from July 29, 2027 and updates from August 31, 2027.
The Bottom Line
You have about five weeks. Start with the breaking-changes list, size the work honestly, and if the team cannot absorb two or three engineer-weeks this month, bring in help instead of slipping. If you want a senior .NET engineer for the upgrade, request a shortlist or browse available engineers.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
