Here’s the calendar quirk that makes this year’s .NET planning unusual: .NET 8, the LTS release, and .NET 9, the STS release, both end support on November 10, 2026, the same day. Normally the support trains are staggered and teams hop from LTS to LTS on their own rhythm. This November, everyone on 8 or 9 hits the wall together.
The good news: the move is singular. Go to .NET 10, the current LTS, once, deliberately, before the Q4 crunch. As of June 2026 you’ve got five months, one budgeting cycle and a couple of sprint boards, not an emergency. The teams that hurt in December will be the ones who treated November as a December problem.
We’re gmware, a software engineering firm with our US office in Austin, TX and delivery centers in Bangalore and Mohali, India. Framework upgrades are the unglamorous half of our legacy modernization practice, so this is a runbook we actually run. Below: why both versions die at once, what the 8-to-10 jump involves, effort by app profile, and the bundle play that catches your SQL Server and Windows 10 stragglers in the same window.
The November 2026 deadline at a glance
Two versions, one date
It’s the support cadence doing what it says. LTS releases get a long runway, STS releases get a short one, and this cycle the two trains arrive at the station together: Microsoft’s 2026 end-of-support roundup lists .NET 8 and .NET 9 against the same November 10, 2026 date.
The practical consequence matters more than the trivia. There’s no refuge in 9. A team on .NET 8 can’t buy time by stepping forward one version, because the version ahead of them dies the same Tuesday. The only move that converts this deadline into multi-year quiet is the current LTS, .NET 10. One target, one migration, every supported team lands in the same place.
What stops on November 10, 2026
Patches. Your services keep compiling and running; nothing about the runtime self-destructs at midnight. What ends is the security-update stream for the runtime, the SDK, and ASP.NET Core on those versions. From that date forward, every disclosed vulnerability is one you can’t patch without changing framework versions, which means doing the upgrade you were avoiding, except under incident pressure instead of on a sprint board.
Unsupported frameworks also surface in paperwork long before they surface in incidents. SOC 2 and PCI reviews, customer security questionnaires, and cyber-insurance renewals all ask for your version inventory; an EOL framework on that list is a finding someone has to explain in writing, every cycle, until it’s gone. Auditors don’t scan your binaries; they read your inventory. Which assumes you have one. More on that below.
The upgrade path runs straight to 10
Straight to 10, not through 9. Stepping to .NET 9 buys you a framework that dies the same day as the one you’re leaving; there’s no scenario where that’s the plan. .NET 10 is the current LTS and the only target worth the regression-testing bill.
The “never skip a version” instinct is mostly a holdover from the old .NET Framework era. Modern .NET tolerates version jumps well: you review the official breaking-change notes for each major you cross, fix what the compiler and analyzers flag, and let the test suite tell you the rest. That last clause is the honest dependency. Teams with thin test coverage feel framework upgrades far harder than any changelog suggests, because the breakage they hit is the silent-behavior kind, not the compile-error kind.
Step to 9 or jump to 10?
What the 8-to-10 upgrade involves
For a typical service, the mechanics are unglamorous: bump the TargetFramework, take the new SDK in CI, update NuGet packages to versions that target 10, walk Microsoft’s migration notes for the majors you cross, fix the compiler and analyzer findings, then make the regression suite earn its keep. Run the CI matrix against both versions during the transition so feature work keeps landing without a code freeze, and roll out service by service: canary first, big-bang never.
The part that surprises teams is never the framework itself. It’s the third-party graph: the logging adapter that hasn’t shipped a compatible release, the abandoned open-source dependency nobody owns anymore, the internal shared library pinned three majors back that four other teams also consume. Inventory those first, because they set your critical path, and occasionally your build-vs-replace decisions.
How big is the job? Effort by app profile
| App profile | Typical effort | Watch for | Recommended path |
|---|---|---|---|
| .NET 8 service, current packages, CI + tests | Small, contained, per service | Minor breaking changes across two majors | TargetFramework bump to 10 this quarter |
| .NET 9 app built greenfield last year | Small | Teams assuming the STS runway was longer | Move at the next sprint boundary; adopt an LTS-only policy after |
| Multi-service estate, mixed versions, stale NuGet graph | Medium to large | Transitive dependency conflicts; abandoned packages; shared internal libraries | Inventory, risk-rank, batch services by dependency cluster |
| .NET Framework 4.x legacy | A modernization project, not an upgrade | Windows-coupled APIs (WebForms, WCF), lost specs | Strangler-style port on its own budget line |
Two notes on reading that table. Effort lives at the service level, so don’t let anyone quote your whole estate as one number. The spread between your best and worst service is the actual story. And the Framework 4.x row is a different universe with different economics; our modernization cost guide covers the rewrite-vs-refactor-vs-rehost math that applies there.
The rest of the 2026 EOL calendar
The November date isn’t arriving alone. 2026 is a Microsoft-ecosystem pile-up:
| Product | End of support | What it means |
|---|---|---|
| MySQL 8.0 | April 30, 2026, already passed | No more security patches; 8.4 LTS is the move |
| SQL Server 2016 | July 14, 2026 | ESUs escalate at 75%, 150%, then 300% of license price |
| Windows 10 | Already EOS; paid bridge to Oct 2028 | ESUs cost $61, then $122, then $244 per device per year |
| .NET 8 + .NET 9 | November 10, 2026 | Runtime and ASP.NET Core patches end |
2026 end-of-support calendar
SQL 2016 ESU, as % of license price
Windows 10 ESU, dollars per device per year
The bundle play is simple: one inventory, one planning cycle, one modernization window that sweeps all of it, instead of three reactive scrambles spread across the year. The procrastination data says most shops won’t. When Windows 10 went EOS, 18% of partners’ customers had no defined migration path and another 29% didn’t plan to upgrade until six months past the deadline or later. ESU invoices are built on those numbers.
How shops met the last big deadline
AI-assisted refactoring, with supervision
It does speed this up, with adult supervision. Framework upgrades are exactly the work current coding agents are good at: mechanical churn (TargetFramework bumps, API renames, package updates) repeated across dozens of repos, plus generating the characterization tests that thin suites are missing before you touch anything. We use them for both, and on multi-repo estates the cycle-time difference is real.
The supervision clause isn’t optional, though. Unreviewed AI output creates its own debt. Roughly half of AI-generated code contains security vulnerabilities, which is why we wrote a separate rescue guide for AI-generated codebases. Every AI-produced change in our upgrade pipelines lands behind the same gates as human code: compiler and analyzers, the full test suite, then a senior engineer with the authority to say no.
Risk-ranking the inventory
Rank by blast radius, not by convenience:
- Internet-facing services and regulated data (PHI, card data) go first. An unpatchable vulnerability there costs real money and audit findings.
- Revenue-critical internal services go second. An outage hurts, but the attack surface is smaller.
- Low-traffic internal tools go last. They can trail the deadline a few weeks with eyes open and a dated plan.
- Anything scheduled for retirement doesn’t get upgraded at all. Document the exception, write down the kill date, and spend the effort where there’s a future.
Sequence by blast radius, not convenience
If the inventory itself doesn’t exist, that’s the real first task, and it’s the cheapest one on this whole page. A spreadsheet of services, framework versions, package staleness, and data sensitivity turns November from a guess into a sequencing problem.
How gmware runs an upgrade window
We start with the inventory and risk-rank, priced as a short fixed-scope engagement, because every bad upgrade quote we’ve ever reviewed skipped that step. Then upgrades run in batches: an Austin-side architect owns sequencing and review gates, engineers in Bangalore and Mohali run the per-service mechanics and regression passes overnight your time, and the overlap hours cover cutovers and the surprises. When you want the same window to catch your database and OS stragglers, that’s product engineering and modernization under one plan instead of three vendors pointing at each other.
One honest caveat: demand for this work compounds as deadlines stack. Modernization is already a $21.9 to 30B market in 2026, projected toward roughly $92B by 2034, so June planning gets you a calmer calendar and better engineers than an October scramble does.
Five months is plenty if you start while it’s still a planning problem. Tell us what’s in your estate and we’ll come back within 48 hours with a risk-ranked inventory plan, per-batch effort estimates, and a straight answer on what to upgrade versus retire.