Azure Functions .NET 8 End of Support: The Isolated Worker Warning Explained

The short answer

Azure Functions stops supporting .NET 8 on 10 November 2026. That date applies to .NET 8 on the isolated worker model and to the in-process model, and Microsoft retires the in-process model itself on the same day. Function apps do not switch off. Microsoft's policy says they can still be created and deployed and continue to run, but they no longer get security patches, new features or performance work, they are not eligible for support until you upgrade, and in some cases Microsoft may limit their instances, down to scaling to one. The supported destination is .NET 10 on the isolated worker model, which Functions supports until 14 November 2028.

The date comes from the runtime itself: see our .NET 8 end of life page for what ends across the whole platform. This post covers what it means inside Azure Functions.

What the ".NET 8 isolated will reach EOL on 11/10/2026" warning means

Many teams first meet this as a message along the lines of "Upgrade your app to newer version as .NET 8 isolated will reach EOL on 11/10/2026". The date is US format: 10 November 2026. It is a retirement notice, not an error, and nothing in your app is broken.

Azure Functions ties each language version to its upstream lifecycle. Microsoft's language support policy says support ends on whichever comes first, the community end-of-support date for the language or the end of support for the base operating system. For .NET 8 that is the .NET 8 end of support date Microsoft set for the runtime: 10 November 2026. Before a retirement, the Functions team sends notification emails about the apps it affects. The warning is that notice applied to your app.

.NET versions on Azure Functions and their end dates

Functions now runs only on version 4.x of the host. The supported .NET version depends on the execution model.

.NET 9 originally had an end date of 12 May 2026. Microsoft moved standard-term releases to 24 months of support, which put .NET 9 on the same day as .NET 8. Moving from 8 to 9 therefore buys nothing; our .NET 9 end of support page explains why.

In-process vs isolated worker: why it matters now

In the in-process model, your function code runs inside the Functions host process. That model only ever supported long-term support releases, and today it supports only .NET 8. Microsoft states that .NET 10 is not supported in-process. In the isolated worker model, your code runs in its own .NET worker process, so it can target any supported .NET version, including .NET Framework 4.8 for apps that need it.

So the work depends on where you start:

• In-process on .NET 8: two changes, done together. You move to the isolated worker model and to .NET 10. There is no in-process .NET 10 to land on.
• Isolated worker on .NET 8 or .NET 9: one change. Retarget to net10.0, update the worker packages and change the app's stack setting.

An in-process app on .NET 8 has the settings FUNCTIONS_WORKER_RUNTIME=dotnet and FUNCTIONS_INPROC_NET8_ENABLED=1. An isolated app has FUNCTIONS_WORKER_RUNTIME=dotnet-isolated.

What keeps running and what stops after 10 November

The scale limit is the part teams tend to miss. A low-traffic app may never notice it. An event-driven app that relies on scale-out to drain a queue would.

The Linux Consumption plan trap

If your app runs on the Linux Consumption plan, upgrading the .NET version in place is not enough. Microsoft states that .NET 9 is the last .NET version supported on Linux Consumption, and newer versions are not being added. The Linux Consumption hosting option itself retires on 30 September 2028.

The path to .NET 10 for those apps runs through the Flex Consumption plan. Flex Consumption is Linux only and supports the isolated worker model on .NET 8, 9 and 10. It does not support the in-process model. Microsoft does not support in-place migration from another plan, so you create a new function app on Flex Consumption and redeploy your code. Flex Consumption also has no deployment slots; Microsoft points to its rolling update strategy, currently in preview, for deployments without downtime. On Flex, the runtime is set through properties.functionAppConfig.runtime rather than the FUNCTIONS_WORKER_RUNTIME app setting or linuxFxVersion, which are deprecated there. Microsoft says apps on the Windows Consumption plan are not currently affected.

How to move a function app from .NET 8 to .NET 10

1. Find the apps

Microsoft's migration guide gives an Azure PowerShell script that lists in-process apps in the current subscription:

$FunctionApps = Get-AzFunctionApp
$AppInfo = @{}
foreach ($App in $FunctionApps)
{
     if ($App.Runtime -eq 'dotnet')
     {
          $AppInfo.Add($App.Name, $App.Runtime)
     }
}
$AppInfo

For a single app, check its settings and stack with the Azure CLI:

az functionapp config appsettings list --name "<APP>" --resource-group "<RG>"
az functionapp show --name "<APP>" --resource-group "<RG>" --query "siteConfig.netFrameworkVersion" --output tsv

2. Update the project file

For an in-process project, Microsoft's .NET 10 migration replaces the Microsoft.NET.Sdk.Functions package with the worker packages and a new project SDK. The result looks like this:

<Project Sdk="Azure.Functions.Sdk/1.0.0">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.52.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

Replace each Microsoft.Azure.WebJobs.Extensions.* package with its Microsoft.Azure.Functions.Worker.Extensions.* counterpart, and remove Microsoft.Azure.Functions.Extensions; the isolated model provides dependency injection itself. An app already on the isolated worker only needs TargetFramework set to net10.0 and its worker packages updated to current versions.

3. Add Program.cs and update local settings

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

Program.cs replaces any FunctionsStartup class. In local.settings.json, set FUNCTIONS_WORKER_RUNTIME to dotnet-isolated.

4. Change the function code

• Rename the [FunctionName] attribute to [Function]. The signature is the same, so a search and replace works.
• Remove ILogger method parameters and inject ILogger<T> through the constructor.
• Rename binding attributes: input bindings usually gain an Input suffix and output bindings an Output suffix, so [Queue] becomes [QueueOutput]. Output bindings move off the parameter list onto the return type or a result class.
• Check serialisation. The isolated model uses System.Text.Json, which ignores Newtonsoft attributes such as [JsonProperty] and [JsonIgnore] without raising an error. Properties quietly bind to default values, which is the bug most likely to reach production unnoticed.
• With ASP.NET Core integration, synchronous reads and writes on request and response streams fail. Switch to the async methods.

Then work through the .NET 9 and .NET 10 breaking changes in the rest of the codebase. Our .NET 8 to .NET 10 upgrade guide covers them.

5. Update the app in Azure through a staging slot

Changing FUNCTIONS_WORKER_RUNTIME and deploying the isolated build are two separate restarts. Between them the code and the runtime do not match, and the app throws error AZFD0013. Microsoft's guidance is to do both in a staging slot and swap. Do not mark FUNCTIONS_WORKER_RUNTIME as a slot setting.

# Set the worker model on the staging slot
az functionapp config appsettings set --name "<APP>" --resource-group "<RG>" \
  --slot staging --settings FUNCTIONS_WORKER_RUNTIME=dotnet-isolated

# Windows: set the .NET version
az functionapp list-runtimes --os "windows" --query "[?runtime == 'dotnet-isolated'].{Version:version}" --output table
az functionapp config set --net-framework-version "v10.0" --name "<APP>" --resource-group "<RG>" --slot "staging"

# Linux (Premium or Dedicated): confirm the value, then set linuxFxVersion
az functionapp list-runtimes --os linux --query "[?runtime == 'dotnet-isolated'].{Version:version, linuxFxVersion:linux_fx_version}" --output table
az functionapp config set --linux-fx-version "DOTNET-ISOLATED|10.0" --name "<APP>" --resource-group "<RG>" --slot "staging"

Use the linuxFxVersion value that list-runtimes returns for your region. Publish the migrated project to the staging slot, confirm the errors have stopped and the functions behave, then swap staging into production. A swap applies everything as one update. If you update production directly instead, expect the app to be unavailable for roughly 30 to 60 seconds during the restart.

6. Update your pipelines

Infrastructure as code and CI/CD pipelines often set FUNCTIONS_WORKER_RUNTIME, netFrameworkVersion or linuxFxVersion explicitly. If they still say dotnet or 8.0, the next deployment puts the old values back.

If an app cannot move by 10 November

For most function apps the migration above is a sprint of work, and it is the right answer. Microsoft runs the Functions host and the .NET worker images, so no third party can patch the managed .NET 8 stack inside a Functions plan. OSSeva cannot either, and we do not claim to.

Where OSSeva does help is the code around your functions. Many teams run the same .NET 8 libraries in services on VMs, containers or Kubernetes, where they control the runtime. OSSeva for .NET keeps .NET 8 patched past 10 November 2026 with signed runtime builds and Docker base images, so those services stay covered while the function apps move first. OSSeva Operate also includes .NET version migration execution if you want help with the move itself. 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

Will my Azure Function stop working on 10 November 2026?

No. Microsoft's policy says apps on a retired language version continue to run and can still be deployed. They stop receiving security patches and are not eligible for support, and Microsoft may limit how many instances they get.

What does "upgrade your app to newer version as .NET 8 isolated will reach EOL on 11/10/2026" mean?

It is a retirement notice for a function app on .NET 8 in the isolated worker model. 11/10/2026 is 10 November 2026, the day .NET 8 support ends on Azure Functions. Retarget the app to .NET 10 and update its stack setting to clear it.

When does the Azure Functions in-process model end?

Support for the in-process model ends on 10 November 2026, the same day as .NET 8. In-process supports only .NET 8, so every in-process app has to move to the isolated worker model.

Can I run .NET 10 with the in-process model?

No. Microsoft states that .NET 10 is not supported by the in-process model. To use .NET 10, migrate the app to the isolated worker model.

Should I upgrade my function app to .NET 9 instead?

No. .NET 9 support on Functions also ends on 10 November 2026. Go straight to .NET 10, supported until 14 November 2028.

Does the Linux Consumption plan support .NET 10?

No. .NET 9 is the last .NET version Microsoft supports on Linux Consumption. To run .NET 10 on Linux serverless hosting, create a new app on the Flex Consumption plan and redeploy, since in-place migration is not supported.

Do I need to change FUNCTIONS_EXTENSION_VERSION?

No. .NET 10 runs on version 4.x of the Functions runtime, so the value stays ~4. The settings that change are FUNCTIONS_WORKER_RUNTIME, for in-process apps, and the .NET stack setting.