.NET 8 and .NET 9 End of Support: What to Do Now (2026)

Microsoft has confirmed a date that affects a huge share of business applications running today: both .NET 8 and .NET 9 reach End of Support on November 10, 2026. Not one or the other both, on the exact same day. If your business runs internal tools, customer-facing apps, or APIs built on either version, this is a deadline worth planning around now rather than in October.

This isn't a niche developer concern. .NET 8 was one of the most widely adopted LTS releases in the platform's history, and .NET 9 shipped only a year ago a large share of applications built or upgraded in the last two to three years are sitting on one of these two versions right now.

Here's what the deadline actually means, why two different .NET versions ended up expiring on the same day, what a realistic migration plan looks like, and what it typically costs to get there without disrupting production.

Why .NET 8 and .NET 9 Are Both Expiring at Once

This wasn't a scheduling coincidence it's the result of a policy change Microsoft made partway through .NET 9's life. Here's how the two versions ended up on the same clock:

• .NET 8 shipped November 14, 2023 as a Long Term Support (LTS) release, which carries a standard 36-month support window — landing its End of Support on November 10, 2026.
• .NET 9 shipped November 12, 2024 as a Standard Term Support (STS) release. STS releases originally got 18 months of support, which would have put .NET 9's end date around May 2026. Partway through .NET 9's service window, Microsoft extended the STS support policy from 18 to 24 months — and .NET 9 was the first release to get the extension, pushing its End of Support to line up exactly with .NET 8: November 10, 2026.^[1]

The practical result: whether you built on the "stable LTS choice" or the "newer STS release," you're facing the same deadline.

What "End of Support" Actually Means for Your Applications

Your application will not stop working on November 11, 2026. That's what makes this deadline easy to underestimate. According to Microsoft's own announcement, here's what actually changes the day after:^[1]

• No new security updates. Any vulnerability discovered in .NET 8 or .NET 9 after that date doesn't get patched.
• No technical support. If something breaks tied to the runtime itself, Microsoft support won't help you fix it.
• Tooling starts flagging it. A future Visual Studio 2022 update will mark .NET 8 and .NET 9 components as out of support.
• One possible final patch. Microsoft may ship one last update on the cutoff date if a known critical issue is already in the pipeline — but that's the last one, ever.

This Is a Recurring Pattern, Not a One-Off

If this feels like the same conversation you had a couple of years ago, that's because it is. .NET Core 3.1 reached end of life in December 2022, .NET 6 in November 2024, and .NET 7 under the old 18-month STS policy even earlier, in May 2024. Each time, the pattern was identical: applications kept running, nothing visibly broke, and the risk built quietly until a vulnerability surfaced or a hosting provider dropped support.

What's different this time is that the STS policy extension means two versions are expiring together instead of on staggered schedules which is why this deadline is getting more attention than a typical single-version cutoff. Businesses that treated previous EOL dates as a "someday" problem generally paid for it later, either in an emergency migration or an unpatched vulnerability nobody caught in time.

Why .NET 10, Not .NET 11

The obvious question is which version to move to. Microsoft's own recommendation is .NET 10, not the newer .NET 11 arriving around the same time as the deadline.

.NET 11 is expected to ship as a new STS release the same month .NET 8 and .NET 9 expire — meaning it would still be brand new, with no real-world production mileage, right when your migration is due. .NET 10 is the current LTS release, already a year into production use, and supported through November 2028. For nearly every business application, that's the safer landing spot.

How to Plan the Migration Without a Fire Drill

November 10, 2026 is the deadline, not a reasonable start date. A realistic plan needs room for testing before that date, not a scramble in the final weeks.

1. Take Inventory First

Before estimating any timeline, list every application, internal tool, and service currently targeting .NET 8 or .NET 9 including anything built by a third-party vendor. If you rely on vendor software, confirm now whether a .NET 10-compatible release exists or is planned.

2. Prioritize by Risk, Not by Convenience

Prioritize internet-facing systems, anything handling sensitive data, shared internal services multiple teams depend on, and applications with limited test coverage these are where an unpatched vulnerability does the most damage, and where a rushed upgrade is most likely to go wrong.

3. Build In Real Testing Time

Most .NET 8-to-10 upgrades involve minimal breaking changes, but "minimal" isn't "none." Budget time for updating the target framework, testing dependencies for compatibility, and validating behavior under real traffic not just a passing build.

4. Roll Out in Stages

A staged deployment — starting with lower-risk internal tools before customer-facing systems catches problems while the blast radius is still small, rather than after every user is already on the new version.

What This Migration Typically Involves and Costs

For a single, well-tested application with modern dependencies, a .NET 8 or .NET 9 to .NET 10 upgrade is often a matter of days updating the target framework, resolving a handful of package compatibility issues, and running the existing test suite. Microsoft has intentionally kept breaking changes minimal between recent versions to make this kind of upgrade low-friction.

The real cost driver isn't usually the framework upgrade itself — it's everything around it: thin or missing test coverage that needs manual verification, older third-party libraries that haven't been updated for newer runtimes, and CI/CD configuration that assumes a specific .NET version. A handful of well-maintained applications might take a few weeks; a decade of accumulated, lightly maintained internal tools is a materially larger project.

Either way, doing this proactively is consistently cheaper than doing it reactively. A planned migration allows staged rollout and real testing. An emergency migration triggered by a discovered vulnerability or a hosting provider dropping support compresses the same work into far less time, under far more pressure, at a higher price.

Frequently Asked Questions

Will my application stop working when .NET 8 or .NET 9 reaches end of support?

No. Applications continue running normally after November 10, 2026. What stops is security patching and Microsoft technical support the risk is invisible until an unpatched vulnerability is discovered.

Why do .NET 8 and .NET 9 both expire on the same day?

.NET 8 is an LTS release with a standard 36-month window ending November 10, 2026. .NET 9 is an STS release that would have expired earlier under the old 18-month policy, but Microsoft extended STS support to 24 months starting with .NET 9, landing its end date on the same day as .NET 8.

Should we upgrade to .NET 10 or wait for .NET 11?

Microsoft recommends .NET 10. It's the current LTS release, supported through November 2028, and already stable in production. .NET 11 is expected as a brand-new STS release arriving the same month the deadline hits, leaving no time to validate it before you're required to move.

How risky is it to stay on .NET 8 or .NET 9 past the deadline?

The risk grows over time rather than appearing immediately. Without security patches, any vulnerability discovered after the cutoff goes unfixed a real example being a critical .NET 6 vulnerability that Microsoft excluded from patching once that version had expired.

How long does a .NET 8 or .NET 9 to .NET 10 migration typically take?

It depends on application count, complexity, and test coverage. Most individual applications see minimal breaking changes, but businesses with several applications should start with an inventory and prioritize by risk rather than assuming a single, fast, company-wide upgrade.

What should we do if we rely on third-party software built on .NET 8 or .NET 9?

Contact the vendor now to confirm whether a .NET 10-compatible version is available or planned. Waiting until closer to the deadline reduces your options if the vendor's own timeline doesn't line up with yours.

Start the Inventory Now, Not in October 2026

November 10, 2026 will arrive whether or not a migration plan is in place the only real choice is whether your team gets there with a tested, staged rollout or a last-minute scramble across every application still on .NET 8 or .NET 9. As an experienced .NET development company, DotStark can inventory your current applications, prioritize what needs to move first, and manage the upgrade to .NET 10 without disrupting what's already running in production.

If your applications are hosted on Azure, this is also a natural moment to review your broader Azure cloud environment alongside the runtime upgrade, since hosting configuration and deployment pipelines often need updates in step with the framework itself.