.NET 8 and .NET 9 Stop Getting Patches on November 10. Upgrade to .NET 10 Now

Upgrade to .NET 10 before November 10

If your app runs on .NET 8 or .NET 9, mark November 10, 2026 on your calendar. That is the day both versions stop receiving free patches and security fixes from Microsoft. After that date, every unpatched vulnerability in those runtimes is yours to carry, and your users will not know or care that the runtime vendor moved on.

The good news is that the upgrade path is clear. .NET 10 is the current long-term support release, covered until November 2028. It shipped on November 11, 2025, and it is the version Microsoft wants cautious teams on. The .NET team also published .NET 11 Release Candidate 2 on October 13, 2026, for teams that want to preview the next standard-term release, but .NET 10 is the safe default.

How .NET support works

Microsoft ships a new .NET version every November. Even-numbered versions are long-term support releases with three years of free patches. Odd-numbered versions are standard-term support releases with roughly two years. That rhythm is predictable, which is why there is no excuse for being surprised by it, even though plenty of teams are surprised every cycle.

The dates for this cycle: .NET 8, an LTS release from November 2023, ends support November 10, 2026. .NET 9, an STS release from November 2024, ends the same day. .NET 10, the LTS release, runs to November 14, 2028. If you are choosing a target today, the choice is .NET 10, unless you have a specific reason to ride the STS train.

What happens if you do nothing

Nothing breaks on November 11. Your apps keep running. That is precisely the danger. End of support is not an outage; it is a slow leak. New vulnerabilities in the runtime, the libraries, and the tooling stop getting fixed for your version, while attackers keep finding them. Compliance frameworks notice too: running an unsupported runtime is a finding in most audits, and it is an easy one for an auditor to write up.

There is also a dependency trap. Libraries and frameworks drop support for old runtimes on their own schedules. Stay on .NET 8 too long and you will find new versions of packages you need require .NET 10 anyway, turning a planned migration into a forced one under worse conditions.

The migration, step by step

Start with an inventory. List every app, service, and job running on .NET 8 or 9, including the ones nobody owns anymore. Those orphaned services are usually the ones that bite. Check your target framework in each project file, then check your third-party packages for .NET 10 compatibility. Most mainstream libraries already support it.

Next, upgrade in a branch, run your test suite, and watch for the usual suspects: deprecated APIs, behavior changes in serialization or cryptography, and container base images that need updating. The .NET team publishes breaking-change notes for each release; read them before you start, not after something fails in staging.

Then deploy in stages. Move internal tools first, then low-risk services, then the critical paths. Keep the old runtime available for rollback during the rollout window, and remove it once you are confident. If you run containers, rebuild your images on the .NET 10 base image rather than patching old images in place.

Should you jump to .NET 11 RC2 instead?

For most teams, no. Release candidates carry a go-live license, and .NET 11 RC2 is a solid preview, but it is not the long-term support choice. Its general availability is expected in the November 2026 cycle, and it will be a standard-term release. If you are already planning a migration, target .NET 10 now and evaluate .NET 11 on its own schedule, not as a shortcut past the deadline.

The exception is teams that already track the latest release closely and have the testing capacity to validate a release candidate properly. For everyone else, the boring choice is the right one. This is the same advice we gave when Python 3.10 reached end of life: upgrade to the supported LTS, test properly, and stop treating runtime versions as background noise.

The bottom line

November 10 is a week away. Upgrade to .NET 10, test it, ship it, and put the next support deadline in your calendar the day you finish. The teams that treat runtime support as a routine will never have to explain to a customer why their app runs on software nobody patches anymore.