Azure App Service .NET 8 End of Support: What Happens to Your Web App

The short answer

.NET 8 web apps on Azure App Service reach end of support on 10 November 2026, because App Service follows the community lifecycle of each runtime and that is the day Microsoft ends support for .NET 8. Your app keeps running unchanged after that date. What stops is App Service's ability to provide security patches or customer support for the .NET 8 stack, and Microsoft requires an upgrade to a supported version before it will support the app. The supported destination is .NET 10, the long-term support release that runs to 14 November 2028.

For what ends across the .NET runtime as a whole, see our .NET 8 end of life page. This post covers what happens inside App Service.

What App Service's runtime policy says

Microsoft's language runtime support policy for App Service is short and specific:

• App Service follows community support timelines for each runtime. It keeps each major version of a stack updated and controls which minor and patch version runs.
• After a runtime's end of support, apps that use it continue to run unchanged.
• App Service cannot provide security patches or related customer support for that runtime version after the date.
• An app on an unsupported language version has to be upgraded before it can get App Service support.

Microsoft's App Service configuration guide adds what happens in the portal. Outdated runtimes are removed from the create and configure pages, and apps still using them keep running. You can still create an app on a runtime hidden from the portal through the Azure CLI, an ARM template or Bicep. If a runtime is removed from the platform entirely, the subscription owner gets an email before the removal.

What keeps running and what stops

Who receives the end-of-support notice

App Service sends reminder notifications about upcoming end-of-support dates to subscription owners, specifically account administrators, service administrators and coadministrators. Contributors, readers and other roles do not receive them unless they opt in through Service Health alerts. If the people who own the web apps are not subscription administrators, they may never see the notice. Setting up a Service Health alert for the team that runs the apps closes that gap.

Windows and Linux work differently

How an App Service app picks its .NET version depends on the operating system.

One CLI detail trips people up. az webapp config set has a --net-framework-version flag, but Microsoft's CLI reference describes it as the version used "if using .NET Framework", with values such as v4.0. For ASP.NET Core on Windows, Microsoft's App Service guide says to set the target framework in the project file.

Two deployment patterns that change nothing when you change the stack

Self-contained deployments. A self-contained publish carries its own copy of the .NET runtime, and Microsoft's .NET documentation notes that such an app does not roll forward to the latest security patch; the runtime only changes when you release a new version of the app. A self-contained .NET 8 app stays on its bundled .NET 8 runtime whatever App Service has installed. Each one has to be rebuilt.

Custom containers. If the web app runs from your own container image, App Service does not manage the .NET runtime inside it. The base image decides, which makes it your responsibility to move. Our post on .NET 8 Docker images after end of support covers what happens to the mcr.microsoft.com 8.0 tags.

How to move an App Service web app from .NET 8 to .NET 10

1. Inventory the apps and their stacks

On Linux, list the web apps and read each one's stack:

for app in $(az webapp list --query "[].[name,resourceGroup]" -o tsv | tr '\t' ','); do
  name=${app%,*}; rg=${app#*,}
  echo "$name $(az webapp config show --name "$name" --resource-group "$rg" --query linuxFxVersion -o tsv)"
done

Anything showing DOTNETCORE|8.0 is in scope. On Windows, check the TargetFramework in each project, or run dotnet --info in Kudu. List the stacks App Service currently offers with:

az webapp list-runtimes --os linux | grep DOTNET

2. Retarget the project

<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>

Update Microsoft.AspNetCore.*, Microsoft.EntityFrameworkCore.* and Microsoft.Extensions.* packages to their 10.x versions, and update global.json if you pin the SDK. Moving from 8 to 10 crosses two major versions, so work through the breaking changes in both. Our .NET 8 to .NET 10 upgrade guide lists the ones that break builds most often.

3. Deploy to a staging slot and change the stack there

# Linux: switch the staging slot's runtime stack to .NET 10
az webapp config set --name "<APP>" --resource-group "<RG>" \
  --slot staging --linux-fx-version "DOTNETCORE|10.0"

# Confirm the change
az webapp config show --name "<APP>" --resource-group "<RG>" \
  --slot staging --query linuxFxVersion

Deploy the net10.0 build to the same slot. On Windows there is no stack value to flip for ASP.NET Core; deploying the net10.0 build is the change. Test in the slot, then swap it into production. Keep the old slot content until you are satisfied, because swapping back is the quickest rollback.

4. Fix your templates and pipelines

Bicep, ARM and Terraform definitions that set linuxFxVersion to DOTNETCORE|8.0 put the old stack back on the next run. So do pipeline tasks that pass a runtime version. Change them in the same pull request as the code.

5. Do the same for the apps nobody remembers

Internal tools, admin sites and webhook receivers are the apps that sit on .NET 8 for years because nothing forces a redeploy. The inventory in step 1 finds them. They keep running after 10 November without patches, which is exactly why they need an owner.

If a web app cannot move by 10 November

For most App Service web apps, retargeting to .NET 10 is the right answer, and a well-tested app can move in days. Some cannot: apps blocked by a dependency that has no .NET 10 release, or by a long certification cycle.

OSSeva does not patch the built-in stacks that Microsoft runs on App Service. App Service does support custom containers, though, and that is where OSSeva fits. OSSeva for .NET keeps .NET 8 patched past 10 November 2026 and ships patched Docker base images for the SDK and the ASP.NET Core runtime, in Alpine and Debian variants. A web app that cannot be retargeted in time can run from a container built on that image and keep receiving fixes while its .NET 10 upgrade runs on its own schedule. Builds are signed with GPG and Sigstore, and OSSeva Operate includes .NET version migration execution when you are ready to move. See .NET 8 extended support and our comparison of .NET 8 extended support providers. OSSeva for .NET is priced per application runtime environment; book a discovery call for a quote.

Frequently asked questions

When does .NET 8 support end on Azure App Service?

On 10 November 2026. App Service follows the community lifecycle of each runtime, and Microsoft ends .NET 8 support on that date.

Will my App Service web app stop working after .NET 8 end of support?

No. Microsoft states that apps using an end-of-support runtime continue to run unchanged. App Service stops providing security patches and support for that runtime, and you need to upgrade before Microsoft will support the app.

Why can't I select .NET 8 in the portal any more?

App Service removes outdated runtimes from the portal's create and configure pages. Apps already on them keep running, and you can still create one with the Azure CLI, an ARM template or Bicep while the runtime remains on the platform.

How do I change the .NET version of an App Service app on Linux?

Run az webapp config set with --linux-fx-version "DOTNETCORE|10.0", ideally on a staging slot, after deploying a build that targets net10.0. Check the result with az webapp config show --query linuxFxVersion.

How do I change the .NET version on Windows App Service?

Set the target framework in the project file to net10.0 and redeploy. The Windows instances already have the supported .NET versions installed, and Microsoft documents --net-framework-version for .NET Framework apps rather than ASP.NET Core.

Will App Service upgrade my app to .NET 10 automatically?

No. App Service updates minor and patch versions within a major version, but moving from .NET 8 to .NET 10 is a change you make: retarget, redeploy and, on Linux, change the stack setting.

Should I move to .NET 9 on App Service?

No. .NET 9 support ends on the same day as .NET 8, 10 November 2026. Move to .NET 10.