.NET 8 Reaches End of Support on 10 November 2026: The Upgrade Path to .NET 10 on Azure

.NET 8, the long-term support release that shipped in November 2023, reaches end of support on 10 November 2026. So does .NET 9. The second one surprises people: .NET 9 was originally scheduled to end on 12 May 2026, but during its service window Microsoft extended standard-term support releases to 24 months starting with .NET 9, which moved its end date onto the same day as .NET 8's.

Both releases are already in what Microsoft's release policy calls the maintenance phase, the last six months of support, where improvements are limited to security fixes. After 10 November there are none. No patches, no security fixes, no Microsoft technical support for those versions. The date is a Patch Tuesday, and Microsoft's stated practice is that a version gets its final patch on that day if a critical issue exists, and nothing after.

From today, 6 September 2026, that is 65 days. Just over nine weeks.

The destination is .NET 10. It is the current long-term support release, it shipped on 11 November 2025, and it is supported until 14 November 2028. .NET 11 is in preview and is a standard-term release. Under the current policy, LTS releases get three years and STS releases get two, which is why a line-of-business app should normally land on 10 rather than wait for the next version.

Azure App Service follows the community support timeline for each runtime. Microsoft's language runtime support policy is explicit about what happens next: after a language reaches end of support, applications that use it continue to run unchanged, but App Service cannot provide security patches or related customer support for that runtime version past its end-of-support date. The policy adds one sentence that matters more than the rest: if your app uses an unsupported language version, you must upgrade it to a supported version before it can get App Service support.

Read that as an incident scenario rather than a compliance footnote. The app runs fine until the day it doesn't, and the first thing that happens when you open a support case is that you are asked to upgrade before anyone will look at it.

Azure Functions is stricter. Function apps on a retired language version can still be created and deployed and keep running, but they aren't eligible for new features, security patches or performance optimizations, and Microsoft's policy reserves the right to limit the number of instances allocated to those apps, including limiting scaling to a single instance. For a queue processor or a nightly integration job, that is a production incident with a scheduled date.

Containers age the same way, quietly. The floating .NET image tags are updated only for the supported life of the release, so an image built from the 8.0 tag stops picking up runtime fixes after 10 November regardless of how often your pipeline rebuilds it.

One practical detail: App Service sends the reminder emails to account administrators, service administrators and co-administrators. Contributors and readers, which is what most engineers actually hold, receive nothing unless somebody has configured Service Health alerts. If your notifications go to a mailbox nobody reads, ongoing Azure monitoring and maintenance is the cheapest fix on this page.

If any of your C# function apps use the in-process model, you have a second retirement on 10 November 2026: the in-process model itself. It supports only .NET 8, so there is no version of this where you retarget to .NET 10 and carry on. Microsoft's guidance is to migrate to the isolated worker model, and that is a code change rather than a configuration switch. The host builder, dependency injection, logging and several binding types all move.

The second trap is the hosting plan. .NET 9 is the last .NET version supported for function apps on a Linux Consumption plan, and newer versions are not being added to it. So a .NET 10 upgrade for those apps is also a plan migration, to Flex Consumption. The Linux Consumption plan is itself retiring on 30 September 2028, so the work is not wasted, but it needs to be in the same change window as the runtime move and it needs a real test of scaling, networking and cold-start behaviour.

While you are in there: PowerShell 7.4 function apps also reach end of support on 10 November 2026.

For most ASP.NET Core line-of-business apps on App Service, the runtime move is small and the risk sits elsewhere.

The mechanics are: change the target framework from net8.0 to net10.0, move NuGet packages to supported versions, build on a supported SDK, run the test suite, then set the App Service runtime stack to .NET 10 (LTS), which is available on both Windows and Linux. Microsoft's own support requirements are the checklist here, because a supported app means a supported SDK, a supported target framework and supported packages, all three.

The .NET Upgrade Assistant does the mechanical part. It is built into Visual Studio and available as a command-line tool, it scans projects and dependencies, produces a report before it changes anything, and supports the previous-version-to-latest path as well as .NET Framework and Functions v1 to v3 upgrades.

What actually breaks, in our experience, is the layer around the runtime: an unmaintained NuGet package with no .NET 10 build, a native dependency, an old authentication library, a serializer whose behaviour changed, an integration test that was never run against anything but .NET 8. That is why the useful sequencing is to upgrade in a branch, let the CI/CD pipeline build and test it, and deploy to a staging slot before anything swaps into production.

There is also a slow-burning cost to staying put. The month after a version goes out of support, Visual Studio marks it optional and out of support. Six months later, in-support SDKs start emitting the NETSDK1138 warning when you target it. Your build does not fail on 10 November; it just becomes a little more awkward every quarter.

The table below is the decision most teams need to make once per application. Two notes on the edges of it.

If the app is genuinely retiring within a year, say so in writing, put a date on it and reduce its exposure in the meantime: off the public internet, tightened access, and a security assessment if it handles anything sensitive. An undated "we'll replace it eventually" is how an unpatched runtime survives three more budget cycles.

If you cannot move in time, paid third-party extended support for out-of-support .NET versions exists and is listed in Microsoft's own .NET support documentation, from vendors including HeroDevs and TuxCare. Microsoft does not sell Extended Security Updates for .NET the way it does for Windows Server or SQL Server. Those vendor fees are yours, they buy time rather than a fix, and the upgrade still has to happen.

At the other end, some apps should not be retargeted at all. If the thing is a Web Forms application, a desktop app pretending to be a service, or a codebase nobody has compiled in two years, the honest options are modernization, containerization as a holding pattern, or a rebuild. Retargeting a codebase you cannot test is not an upgrade; it is a deployment with a fuse on it.

Week one is inventory, and it is the step people skip. List every App Service, function app and container image and record the runtime version each one actually runs, not the version in the repo. The Azure CLI gives you this in an afternoon across subscriptions. Include the build agents and the base images, and note which apps have a working test suite and which do not.

Week two is triage. Sort each app into one of the paths in the table, and get the in-process function apps and the Linux Consumption apps to the top of the list, because those are the only two that need more than a retarget.

Weeks three to six are the upgrades themselves, in branches, smallest and best-tested apps first, so that the pipeline and the rollback path are proven on something low-risk before you take on the app that runs invoicing.

Weeks seven and eight are staging slots, swaps and verification under real load. Week nine is the buffer you will need, because one app will surprise you.

If your team can carry the code but not the Azure side, or the other way round, hourly cloud engineering fills the gap without a project wrapper. If the apps are still on a web server that never moved, migration to Azure App Service and the runtime upgrade are one piece of work, not two.

This deadline rarely arrives alone. The same line-of-business app usually sits on a Windows Server and a SQL Server with lifecycles of their own, and two of those dates are already in the same quarter: Extended Security Updates for Windows Server 2012 and 2012 R2 end on 13 October 2026, and SQL Server 2016 left extended support on 14 July 2026. An app upgraded to .NET 10 on an unsupported server underneath has moved the problem, not solved it.

We keep a running list of the Microsoft dates that affect customers on this site, with what each one changes and what the options are, at Microsoft deadlines. If .NET is your only item on it this autumn, you are in better shape than most.