The countdown to November 10, 2026: what .NET 8 and .NET 9 end of support actually means
Microsoft has confirmed that .NET 8 and .NET 9 both reach end of support on the same day. If you're running either on Azure App Service or Azure Functions, here's what genuinely changes, what doesn't, and why this is a smaller job than it might sound.
The date that matters
| Version | Release type | End of support |
|---|---|---|
| .NET 8 | Long-Term Support (LTS) | 10 November 2026 |
| .NET 9 | Standard-Term Support (STS) | 10 November 2026 |
| .NET 10 | Long-Term Support (LTS) | Supported through November 2028 |
.NET 8 launched in November 2023 and, as an LTS release, carries a three-year support window. .NET 9's support was extended to line up with that same date, which is why two versions with different release types end up expiring together rather than months apart.
What actually happens on that date
Nothing breaks the moment the clock strikes. Applications running on .NET 8 or .NET 9 keep running exactly as they did the day before. What stops is everything behind the scenes that keeps a runtime trustworthy over time:
No more security patches
The next critical vulnerability discovered in the .NET 8 or .NET 9 runtime will not be fixed by Microsoft, regardless of severity.
No more technical support
Microsoft support channels stop covering issues specific to these versions, including through Azure support plans.
Dependencies move on without you
Microsoft's own libraries — Entity Framework Core, ASP.NET Core, the Azure SDKs — all track to .NET 10. Smaller open-source packages and slower-moving vendor SDKs are the real risk area to check.
Compliance exposure
Frameworks like PCI DSS, HIPAA, ISO 27001, and SOC 2 commonly require running software within its vendor-supported lifecycle. Running past end of support can become an audit finding even if nothing has technically gone wrong.
Why this is specifically an Azure question
If you're hosting on Azure App Service or Azure Functions, the runtime lifecycle isn't just a Microsoft policy document — it directly affects what your hosting platform will let you run:
Azure Functions, both worker models
The in-process and isolated worker models are both tied to the underlying .NET runtime version. Neither has an independent support lifecycle — if the runtime is out of support, so is your function app.
App Service runtime stacks age out
Cloud hosting platforms follow Microsoft's own lifecycle guidance. Expect .NET 8 and .NET 9 options to eventually be phased out of new runtime stack listings, even if existing deployments keep running for a while longer.
Support agreements exclude EOL runtimes
Vendor and infrastructure support agreements typically exclude issues tied to software that's past its own vendor's supported lifecycle — including yours with Microsoft, and potentially your hosting provider's terms with you.
This is a smaller job than a legacy migration — if you start now
If you're running .NET 8 or .NET 9 today, you're in a fundamentally different position from a business still on WebForms or .NET Framework. You're already on modern, cross-platform .NET — this is a runtime version upgrade, not an architectural rewrite. The two things worth doing before November are:
Audit third-party dependencies
Check every NuGet package outside Microsoft's own libraries for .NET 10 compatibility. This is almost always where real migration risk lives, not in your own application code.
Confirm test coverage before you upgrade
Every major .NET release includes some breaking changes. Good test coverage on critical paths turns an upgrade into a routine task; thin coverage turns it into a guessing game about what silently changed.
Still on .NET 8 or .NET 9?
The Stack Assessment gives you a scored read on where your dependencies and test coverage actually stand, in five questions, before you commit to an upgrade timeline.
// or contact us to talk through your timeline