The .NET Double Cliff: Two Versions, One Deadline

On November 10, 2026, both .NET 8 and .NET 9 reach end of support. The same day.

That's roughly five months away, and it's a weird situation. Normally, choosing a Long Term Support release buys you a comfortable runway. Your version ages out while the next LTS has already been in production for a year or two, and you upgrade on your own schedule. This time the runway disappears for two versions at once. The teams that picked .NET 8 for its stability and the teams that jumped to .NET 9 for the newest features are standing on the same ledge, looking at the same date.

If you have production workloads on either version, this is a hard deadline, and it's worth understanding . 

Why the two dates land on top of each other

.NET ships a new major version every November. Even-numbered releases are Long Term Support (LTS) with three years of patches; odd-numbered releases are Standard Term Support (STS) with a shorter window. .NET 8 is LTS, .NET 9 is STS. On paper, those two should expire at different times. Here's how they ended up colliding.

.NET 8 (LTS) shipped in November 2023 on a three-year support clock. Three years lands it on November 10, 2026. (You can also read that as the LTS rule that a version is supported until twelve months after its successor ships and .NET 10 shipped on November 11, 2025. Same date either way.)

.NET 9 (STS) shipped in November 2024. Standard Term Support was historically eighteen months, which would have ended .NET 9 around May 2026, comfortably before .NET 8. But Microsoft extended STS from eighteen to twenty-four months. That extra six months pushed .NET 9's end of support out to November 10, 2026.

So the irony is worth sitting with: the STS extension was meant to give .NET 9 teams more breathing room. Its actual side effect was to slide .NET 9's deadline directly on top of .NET 8's. The change that was supposed to relax the timeline is the thing that created the double cliff. These are two independent support clocks that happen to ring at the same moment, and there's no further extension coming for either.

Here's the full landscape at a glance:

What end of support costs you

After November 10, 2026, Microsoft stops shipping security patches, bug fixes, and servicing updates for .NET 8 and .NET 9. The runtime keeps running, nothing detonates on the eleventh, but the moment a new CVE is disclosed in the runtime or the framework libraries, it stays unpatched on your stack. You're carrying the vulnerability with no first-party fix coming.

The cost that gets underweighted, though, isn't security. It's compliance. Running an unsupported runtime is an audit finding in its own right: in SOC 2, PCI-DSS, FedRAMP, and HIPAA-aligned environments, "we're on a framework version the vendor no longer supports" is a control failure regardless of whether anything has actually broken. You don't get to wait for an incident. The unsupported status is the finding.

This is what we call the Platform Abandonment Tax: the compounding cost of sitting on a platform version the vendor has walked away from. It starts as a line item, an exception you have to document for the auditor, and it grows from there, because every month you stay, you accumulate more code, more dependencies, and more reasons it's "not the right time" to move.

There's a small industry that exists to help you pay that tax, third-party vendors who will sell you extended patches so you can keep running the dead version a while longer. That's a legitimate option if you're genuinely cornered. But be clear about what it is: you're renting time on a platform Microsoft has already left. The question worth asking is whether that money is better spent moving forward instead.

The obvious wrong move: jumping to .NET 11

When a deadline like this hits, the reflex is to grab the newest version on the shelf. Right now that's .NET 11. For almost every enterprise, that's the wrong call.

.NET 11 is a Standard Term Support release. It's in preview as of early 2026, with general availability expected in November 2026, the same month your current versions expire. .NET 10, by contrast, is LTS: it shipped in November 2025 and is supported through November 10, 2028.

Now look at the support horizons. .NET 10 and .NET 11 lose support at roughly the same time, late 2028. But .NET 10 gets there with a full year of production hardening already behind it. So adopting .NET 11 the month it ships means taking on the risk of a brand-new release to land on the same 2028 support window you'd get from the already-proven LTS. You'd be paying in stability and getting nothing in runway.

The rule of thumb for a stability-driven organization is simple: move LTS to LTS. That's .NET 8 → .NET 10 → eventually .NET 12. .NET 11 is the right target only if you're greenfield, you specifically need a capability that ships in it, and your team is comfortable absorbing the faster STS cadence. (We've written a fuller .NET 10 vs .NET 11 breakdown if you want the feature-level comparison but for the double-cliff decision, .NET 10 is the answer.)

The upgrade itself is the easy part

If you're already on .NET 8 or .NET 9, the move to .NET 10 is low-friction. Both are modern .NET; the breaking changes are minimal; many teams can do it themselves over a sprint or two. The version cliff is the visible deadline. It has a date, so it gets attention. The real exposure in most portfolios is the code that never made it onto modern .NET at all: the .NET Framework 4.8 services, the WebForms apps, the older workloads sitting quietly behind the two versions you're about to bump.

Those don't have a deadline. .NET Framework 4.8's support is tied to the operating system, with no foreseeable end-of-life date. And that's the trap because nothing ever forces the issue. Those apps never make it onto a roadmap. They just accrue Legacy Debt year over year, and increasingly they carry an AI Readiness Tax: every modern tool, every Copilot-style workflow, every AI-assisted capability your competitors are starting to ship assumes a modern codebase, and your oldest apps can't participate.

The double cliff is a useful prompt for a reason that has nothing to do with .NET 8. It's a moment when someone with authority is finally looking at the version map. Use that moment to look at the whole portfolio.

What to do before November

There's enough runway to do this well if you start now. Three steps:

1. Inventory. Get a real version map of your p- what's on 8, what's on 9, what's already on 10, and what's still on Framework or older. If you want an exact answer, ByteInsight is a free, local static-analysis tool that scans your code and tells you which framework versions everything is running. 

2. Triage by deadline and risk. The .NET 8 and .NET 9 apps have a date; schedule the move to .NET 10 and treat it as the routine upgrade it is. The Framework and legacy apps don't have a date which means they carry the larger risk, not the smaller one. Those are modernization decisions, and they've been deferred because nothing forces them.

3. Plan the hard ones deliberately. For the workloads that can't be a simple bump, the first question is how much of the app can actually be modernized before you commit budget to it. That's what a VELO Assessment is for. It shows you the percentage of a legacy application that can be automatically modernized, so you're planning from data.

The double cliff is a small, dated forcing function. 

Frequently asked questions

When does .NET 8 reach end of support? November 10, 2026. .NET 8 is a Long Term Support release that shipped in November 2023 on a three-year support clock.

When does .NET 9 reach end of support? Also November 10, 2026. .NET 9 is a Standard Term Support release; Microsoft's extension of STS from eighteen to twenty-four months moved its end-of-support date onto the same day as .NET 8's.

Should I upgrade to .NET 10 or .NET 11? For most production workloads, .NET 10. It's the current LTS release, supported through November 2028, with a year of production hardening already behind it. .NET 11 is a Standard Term Support release reaching general availability in November 2026 and is appropriate for greenfield projects or teams that need a specific new capability, but not the default target for a stability-focused upgrade.

Is .NET Framework 4.8 affected by this deadline? No. .NET Framework 4.8's support is tied to the operating system and has no fixed end-of-life date, so it isn't part of the November 2026 cliff. That's a double-edged thing: those applications face no deadline, which is often why they're the most neglected and highest-risk code in the portfolio.

How hard is it to upgrade from .NET 8 to .NET 10? For applications already on modern .NET, it's typically a low-friction upgrade with minimal breaking changes. The harder work in most portfolios isn't the 8-to-10 hop, it's the older Framework and WebForms applications that never reached modern .NET in the first place.