Microsoft ends support for .NET 8 and .NET 9 on 10 November 2026. From that day neither version receives security fixes, servicing updates or technical support from Microsoft, although applications built on them keep running. The supported route is .NET 10, a long-term support (LTS) release covered until 14 November 2028, and for most .NET 8 code the upgrade is small.
Below I cover what actually stops, who should worry, the upgrade itself, the paid stopgap if you cannot make the date, and a five-step plan. If part of your estate still runs on .NET Framework, read the last section first. That is a different problem with different dates.
When does .NET 8 support end?
The date is 10 November 2026 for both .NET 8 and .NET 9, confirmed by the .NET team in June 2026. It falls on a Patch Tuesday. Microsoft says each version may get one final update that day if a known critical issue needs it. After that the patches stop.
.NET 8 is an LTS release from November 2023, so it received the standard three years. .NET 9 is a standard-term support (STS) release from November 2024. It would have ended in May 2026, but in September 2025 Microsoft extended STS support from 18 to 24 months, starting with .NET 9. That is why both versions now share one end date. Microsoft’s stated reason was out-of-band packages such as Aspire and Microsoft.Extensions.AI, which often needed newer package versions and quietly pulled STS components into LTS applications.
What stops working after 10 November 2026?
Your applications carry on as before. The table shows what changes around them.
| Area | After 10 November 2026 |
|---|---|
| Your running applications | Keep running on .NET 8 and .NET 9 |
| Security fixes and servicing updates | None from Microsoft |
| Microsoft technical support | Ends for .NET 8 and .NET 9 applications |
| Azure App Service on .NET 8 | Apps keep running, with no security updates and no customer service for .NET 8 (Azure notice, April 2026) |
| Azure Functions on .NET 8 or 9 | Same end date. In-process apps must move to the isolated worker model before upgrading to .NET 10, and Linux Consumption apps must first move to Flex Consumption (Azure notice, September 2026) |
| Visual Studio 2022 | A servicing update marks the .NET 8 and .NET 9 components as out of support |
The Azure Functions row deserves attention. Support for the in-process hosting model itself also ends on 10 November 2026. So a .NET 8 in-process Functions app needs two changes. Move it to the isolated worker model first, then retarget it to .NET 10.
Who is exposed if you stay on .NET 8?
The security risk is plain for anything internet-facing. A vulnerability disclosed after 10 November gets a patch for supported versions only, so a .NET 8 server keeps the hole for as long as it runs.
The compliance risk arrives faster. Version 3.3 of the NCSC’s Cyber Essentials requirements (April 2026) says all software on in-scope devices must be “licensed and supported”. Software that becomes unsupported must be removed, or moved into a defined sub-set that blocks all traffic to and from the internet. Critical and high-risk updates must be installed within 14 days of release. A .NET 8 web application on an internet-facing server after 10 November does not meet that wording unless someone is still supplying fixes.
The scheme’s definition of “supported” matters here. The vendor does not need to be the original author, but it must be able to modify the software to create fixes, and it must state the date when those fixes stop. A third-party extended-support product could qualify on that basis. Confirm it with your certification body before you rely on it.
In my own security-compliance work, supplier questionnaires from larger customers ask the same question in their own words. Answering “yes, unsupported” starts a conversation you would rather not have during a contract renewal.
How hard is it to upgrade from .NET 8 to .NET 10?
For most applications, not very. Microsoft’s instruction for the core change is one line: set TargetFramework to net10.0. Around that you will usually:
- update
global.jsonto a .NET 10 SDK, if you pin one; - move
Microsoft.AspNetCore.*,Microsoft.EntityFrameworkCore.*andMicrosoft.Extensions.*packages to 10.0.x; - change Docker base images, build agents and the App Service or Functions stack setting;
- read the breaking-change lists for .NET 9 and .NET 10, because you are crossing both.
Most entries on those lists are narrow. A few are worth checking in any web application. The default .NET container images now use Ubuntu, which matters if your Dockerfile installs OS packages. dotnet restore now audits transitive NuGet packages, so a build can show vulnerability warnings it never showed before. System.Text.Json now checks for property name conflicts. EF Core 10 has its own list.
A plain .NET 8 to .NET 10 upgrade is a version upgrade, not a rewrite. A capable team can usually run it, and Microsoft’s GitHub Copilot upgrade agent will plan and apply most of it, committing each step so you can review or roll back. It replaces the .NET Upgrade Assistant, which Microsoft has deprecated, and it works with every Copilot plan, including Copilot Free in Visual Studio 2026 version 18.1 or later. I look at what these tools handle and what they miss in my review of Copilot app modernization.
Take a hypothetical ASP.NET Core API with EF Core, a dozen NuGet packages and a decent test suite. The job is package bumps, a pipeline change and a full regression run. A few days of one developer’s time is a fair expectation, and you do not need outside help for it.
Can you pay for extended support for .NET 8?
Microsoft’s announcement offers no extension. It says servicing, security fixes and technical support stop, and it points everyone to .NET 10.
The paid alternative comes from HeroDevs. Its Never-Ending Support (NES) for .NET 8 was announced in April 2026. HeroDevs describes it as a drop-in replacement for the unsupported runtime that keeps receiving security patches, published alongside Microsoft’s Patch Tuesday releases, on Windows and Linux. Pricing is by quote.
Treat it as a stopgap. It makes sense for an application that cannot be upgraded before November because of a hard dependency or a release freeze. It may also keep that application inside the Cyber Essentials definition while you finish. It does not move the code forward, and you pay for every year you stay.
A five-step plan to get off .NET 8
| Step | What to do | Done when |
|---|---|---|
| 1. Inventory | List every application, service, Functions app and container image with its target framework and hosting. Search project files for net8.0 and net9.0. Microsoft publishes a PowerShell script that lists in-process Functions apps in a subscription. | One list, with an owner for every row |
| 2. Triage | Sort the list into three groups: plain .NET 8 or 9 apps, in-process Functions apps, and anything that still depends on .NET Framework. | Each row has a route and a target date |
| 3. Upgrade | On a branch, retarget to net10.0 and update packages, SDK, images and pipelines. Use the Copilot agent or do it by hand. | The solution builds and existing tests pass |
| 4. Verify | Where tests are thin, add characterisation tests around the flows that earn money. Deploy to a staging slot and compare results with the old version. | Behaviour matches the old version on real inputs |
| 5. Cover the gap | For anything not finished by 10 November, choose paid extended support, network isolation, or a written risk acceptance with an end date. | No unsupported runtime faces the internet without a recorded decision |
Steps 1 and 2 are cheap. Do them this week even if the upgrades come later, because they tell you whether step 5 applies to you at all.
What if part of your estate is still on .NET Framework?
Then the dates are different. .NET Framework 4.7, 4.8 and 4.8.1 are Windows components, supported for as long as the Windows version they run on. .NET Framework 4.6.2 has its own end date, 12 January 2027, which is also the day Windows Server 2016 leaves support. Every date is in my Microsoft end-of-support calendar.
Supported or not, those applications do not move to .NET 10 by changing one property. ASP.NET Web Forms and server-side WCF have no direct equivalent in modern .NET. The business rules often sit in code-behind and stored procedures that nobody has read in years. Here an upgrade tool is not enough. The work becomes recording what the system does today, choosing a target for each module, and moving it piece by piece while the old system keeps running.
That is the work I do. The legacy .NET modernisation service starts with a 15-minute call. The fixed-price Blueprint that follows includes one screen or service migrated with passing characterisation tests, so you see the method work on your own code before you agree a price for the rest.
Sources
- Microsoft .NET Blog: .NET 8 and .NET 9 end of support on November 10, 2026
- Microsoft .NET Blog: .NET STS releases supported for 24 months
- Microsoft: .NET and .NET Core support policy
- Azure Updates: Support for .NET 8 (LTS) ends on November 10, 2026 (App Service)
- Azure Updates: Support for .NET 8 and .NET 9 ends on November 10, 2026 (Azure Functions)
- Microsoft Learn: Migrate C# apps from the in-process to the isolated worker model
- Microsoft Learn: Breaking changes in .NET 10
- Microsoft Learn: Migrate from ASP.NET Core in .NET 9 to ASP.NET Core in .NET 10
- Microsoft Learn: .NET Upgrade Assistant overview (deprecation notice)
- Microsoft Learn: GitHub Copilot upgrade FAQ
- NCSC: Cyber Essentials Requirements for IT Infrastructure v3.3 (PDF)
- HeroDevs: Announcing Never-Ending Support for .NET 8
- Microsoft Learn: Lifecycle FAQ for .NET Framework
- Microsoft Learn: .NET Framework lifecycle dates