We are increasing the length of support offered for .NET Standard Term Support (STS) releases from 18 months to 24 months. This change is effective starting with .NET 9, which means .NET 9 will now reach end of support on November 10, 2026. There is no change for Long Term Support (LTS) releases, which will continue to be supported for three years.
Note that all components in the .NET family do not follow the same support lifecycle as .NET, some components ship out-of-band with .NET and have their own independent support lifecycle, today’s announcement does not change that. More information including the end of support dates for .NET and these out-of-band components can be found on the .NET support lifecycle policy site.
How .NET support worked previously
.NET ships a new major release every year in November for a consistent, repeatable roadmap. Even-numbered releases are Long Term Support (LTS) releases and get support, including updates, for three years, or 12 months after the next successor release ships. For example, since .NET 10 will ship on November 11, 2025, .NET 8 is scheduled to reach end of support 12 months later, on November 10, 2026. This has not changed.
| Version | Original release date | Latest patch version | Patch release date | Release type | Support phase | End of support |
|---|---|---|---|---|---|---|
| .NET 8 | November 14, 2023 | 8.0.20 | September 9, 2025 | LTS | Active | November 10, 2026 |
Odd-numbered releases are STS releases and were supported, including updates, for 18 months, 6 months after the next successor release shipped. For example, since .NET 10 will ship on November 11, 2025, .NET 9 was scheduled to reach end of support on May 12, 2026.
| Version | Original release date | Latest patch version | Patch release date | Release type | Support phase | End of support |
|---|---|---|---|---|---|---|
| .NET 9 | November 12, 2024 | 9.0.9 | September 9, 2025 | STS | Active | May 12, 2026 |
STS releases will be supported for 24 months, 12 months from when the successor release ships. This means that .NET 8 and .NET 9 will reach end of support on the same day – November 10, 2026.
Why make this change?
We know some customers choose to stay on LTS versions due to the longer support timeframe available for these releases. Some enterprises even have internal policies requiring development teams only use LTS versions.
At the same time, .NET is evolving fast. We ship more features as out-of-band (OOB) releases on a regular basis where we previously might have waited for the next annual release train. .NET Aspire, Microsoft.Extensions.AI, and the C# Dev Kit are examples of OOB releases that regularly ship new features.
From the previous example you can see that .NET 9 which shipped a year after .NET 8 will reach end of support 6 months before .NET 8 reaches end of support. This can be a problem in some cases.
Sometimes, an OOB release includes a dependency on an updated version of a package that ships in the annual release train. If you have made the choice to stay on LTS releases exclusively and then install one of these OOB releases that will move the LTS package version to a newer STS version this can cause problems. Since the package now belongs to an STS release, you have inadvertently moved part of the runtime from LTS to STS and will receive support and updates per the STS lifecycle for that package. As in the .NET 9 example, this support could end sooner as compared to if you had stayed on .NET 8.
Alternatively, you may discover this problem and choose not to use the OOB release to avoid this problem, which means you’ll miss out on the functionality in the OOB. The STS package version dependency is now an adoption blocker for the OOB.
To solve this problem, we’re making a change to the STS support lifecycle – STS releases will be supported for 24 months, 12 months from when the successor release ships, which means that .NET 8 and .NET 9 will reach end of support on the same day – November 10, 2026.
| Version | Original Release Date | Latest Patch Version | Patch Release Date | Release Type | Support Phase | End of Support |
|---|---|---|---|---|---|---|
| .NET 9 | November 12, 2024 | 9.0.9 | September 9, 2025 | STS | Active | November 10, 2026 |
Now, if an OOB release pulls in a newer package version from LTS (.NET 8) to STS (.NET 9), you’ll still be supported through the same date you’d have had if you stayed on the LTS version. Even if you weren’t using any OOB releases, we expect having a longer support window for STS releases will make it easier to consider STS releases for your needs in the future.
Closing
We think you will like this change. That said, if you’re planning on upgrading from .NET 9 to .NET 10 soon, you should continue with your upgrade plans since .NET 10 brings a lot of new capabilities and better performance.
This whole support policy is a mess.
Three years for LTS is NOT long enough.
The ONLY version of .NET with true “long term support” is .NET Framework 4.8.
Anything less than ten years is short term. You need to confront this or else enterprise and corporate environments will not use .NET.
this comment has been deleted.
I could not agree more.
What makes this whole upgrade story even worse is that the versions are never fully compatible. It’s not just a matter of switching the framework and running the tests again — there are always small, breaking changes hidden somewhere.
For the customer, the new version delivers absolutely zero benefit. Every release note talks about “performance improvements” and “better stability,” but after 35 years in software development, I know that’s mostly marketing noise.
In reality, we upgrade only to keep receiving security patches. It’s pure maintenance work with no added value — high effort, high risk, and no...
You can check Stephen Toub’s performance improvements posts that he writes every year, with benchmarks and code that you can run and see by yourself.
If that’s marketing noise, then I’m not sure what you understand by performance improvements.
If you have found issues after upgrading, then report those in GitHub or the Visual Studio’s Dev Community. That’s the only way your feedback will get attention.
I don't want to imply your concern about subtle compatibility changes that create work upgrading is a non-issue, but did want to share that there's a fairly rigorous internal process for including compat breaking changes in the release. Breaking changes always documented on our application compatibility site. If you find a change that is compat breaking and not documented please file an issue to report a bug.
To your point about performance changes being marketing hype, many .NET developers have found the annual performance blogs by Stephen Toub pretty useful and interesting. They're also not light on content, that should give...
this comment has been deleted.
As a user who upgraded from Core 1.0 to Core 8, what we need more is a 3–5 year LTS, similar to Node.js LTS.
Around me, we basically give up using STS releases and wait for the LTS; or we just stick to whatever version we deem stable and continue maintaining the project.
So, what now?
Node.js LTS versions are supported for 3 years as well: https://github.com/nodejs/release?tab=readme-ov-file#end-of-life-releases
Just stick with whatever works for your team and application. If you have a critical application (as some people have commented before here) that can’t be upgraded, stick with .NET Framework. If your application can be deployed or upgraded every 3 years without disturbing your users, then stick with .NET 10+ LTS. If your application can be upgraded every year, then use .NET 11 STS.
I think the main challenge with upgrades isn’t really .NET itself, but the ecosystem and infrastructure around it.
The application code usually builds on the new version with only minor changes, but once you get into incompatible NuGets, DevOps pipelines, Docker images, and regression tests, things quickly get more complex. At that point, it feels less like an upgrade and more like running a separate project.
For small teams this might be done in a day or two, but in enterprise projects with strict QA policies and release controls, even a simple version bump can take weeks.
That’s why many organizations...
Completely agree. I just don’t have enough developers in my team to spend a month every year upgrading to a new version of .NET that will gain us no new customers and no new revenue. Even two years is hard enough to justify. But if we take three years, now we’re out of support and our corporate customers will refuse to use our software any more. The .NET support policy is a joke.