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.
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.
I feel that does not change much. Still for LTS you need to migrate only once in 2 years, what reduce workload on the developers. The way the .NET introduce changes is the problem here. You just drop API, introduce breaking changes in code style rules, etc. Each version is hard step up for migration, the API calls does not exist, code style rules prevent the build. If you want to encourage the people to use the STS version, you should think about the developer expirience for the moment the project switch version.
I would expect for example for code style...
Apple releases a new iPhone every year with a standard support policy up to an iOS version. Most people don't upgrade their phones if they are still happy with them. Some people are forced to buy a new phone due to their phones being broken, or it's wiser to upgrade instead of fixing the stale ones, or they can just take the risk of using the stale ones as long as they can save costs.
I really like this change to STS. However, I believe if we want to incentivize other organizations to upgrade, we should just keep moving on with...
Yup, in our DevOps environment we get a lot of alerts on software running unsupported .NET versions. By the time the software vendor updates it, it seems like that LTS version is about to go out of support as well. This is just madness for all involved.
It’s chaotic. For us we decided to go with the LTS versions from the beginning. Our pain lessons we learnt was during the transition AspNetCore 2.0,2.1, 2.2,3.0 .Net5, .Net 6 Days- We found out that we were in constant cycle of updating our applications every now and then just to stay current with each releases. This policy change is more than welcomed
While this sounds good, it really changes nothing. Companies that require LTS aren't going to suddenly start using STS just because the dates line up. So making this change isn't going to bring people onboard to get adoption rates up. I suspect that is the real rationale here. The # of people using the STS releases isn't high compared to the LTS releases.
I get it, maintaining libraries across multiple versions is hard. This is how the rest of the world does it though. If it is hard to do then why not focus on the solving the problem...
Yes – .NET Framework 4.8 is the only version of .NET with true long term support. It’s a bad joke.
That’s good. We currently adhere to an LTS-only policy as it provides stability and predictably. The longer STS timeframe would enable us consider using odd numbered releases. When looking at new features that are available in later releases, it does feel sometimes that remaining on LTS means we’re missing out on what .Net has to offer.
That's... nice, but what we really want is an LTS release that deserves the name. What .NET currently has is a short-term-support branch (currently called LTS) and a very-short-term-support branch (currently called STS). :-)
Let me explain with an example: You develop a .NET based line-of-business software solution and release it in May 2025. No matter which .NET version you choose (8 or 9), both of them will run out of support 1.5 years later. Sure, I can tell a potential customer that I can only guarantee that my software will run in a supported way for 1.5 years, and, after...
Can’t agree more, 5 years for LTS and 3 years for STS would be great
Yes, exactly.