Migrating .NET in-process Azure Functions to the isolated model

Introduction:

With Microsoft announcing the retirement of the .NET in-process Azure Functions model by November 10, 2026, it’s time for developers to start planning their migration to the isolated worker model. The in-process model has served well for years, but as .NET continues to evolve, the isolated model brings better flexibility, improved runtime isolation, and future compatibility with newer .NET versions.

Migrating to the isolated worker model not only ensures long-term support but also provides developers with greater control over dependencies, improved reliability, and easier maintenance. In this article, we’ll walk through the key differences between the in-process and isolated models, understand why migration is essential, and explore a detailed, step-by-step process to move your existing Azure Function apps to the isolated model safely and efficiently.

In-process vs. isolated:

Execution process:

• In-process: function code runs inside the Functions host process. This can give slightly lower latency but couples your code to host behavior and host-managed dependencies.

• Isolated worker: your code runs in a separate .NET worker process that communicates with the Functions host over a well-defined protocol. This decoupling improves isolation and versioning flexibility.

Dependency scope:

• In-process: host and function share the same .NET runtime; some host dependencies and extensions may be tightly coupled to specific .NET versions.

• Isolated: you control the TargetFramework and full dependency set in your worker project (easier to upgrade to .NET 8, etc.).

Feature parity & behaviors

The models are similar for most triggers and bindings, but behavior can differ for some extension points (custom bindings, certain host integrations). Microsoft documents differences and migration guidance — consult their migration guide when moving production apps.

Migration:

Assumption: your app currently uses the in-process model (FUNCTIONS_WORKER_RUNTIME = dotnet) and you want to move to the isolated model (FUNCTIONS_WORKER_RUNTIME = dotnet-isolated). The migration often includes moving to a newer .NET target (e.g., .NET 8). For authoritative details, see Microsoft’s migration guide.

Step 1

1. In the Azure Portal go to your Function App → Deployment slots → Add Slot.
2. Name it e.g., staging and clone settings from production (or from a slot you prefer).
3. Ensure the staging slot has identical app settings and connection strings initially — you will modify only the minimal settings needed.

Step 2

Convert the project to an isolated worker project structure:

• Ensure <OutputType>Exe</OutputType> (worker runs as an executable).
• Set <TargetFramework> to your desired version (e.g., net8.0).

• Ensure <AzureFunctionsVersion>v4</AzureFunctionsVersion> (Functions v4 supports isolated workers).

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <OutputType>Exe</OutputType>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.*" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.*" OutputItemType="Analyzer" />
  <!-- Add any worker-specific extensions you need -->
</ItemGroup>

Essentially, I utilized GitHub Co-Pilot for vibe coding, which handled the framework and dependency upgrade, and it worked well.

Deploy to staging push these code & package changes to your staging slot so the staging slot runs the code compiled for the isolated worker model.

Step 3

In the Azure Portal, go to your Function App → Deployment slots → select staging → Configuration → Application settings.

Find FUNCTIONS_WORKER_RUNTIME and change its value from dotnet to dotnet-isolated.

Save and restart the staging slot.

Test all your functions, once all works well, swap the slots.

Mark any settings that must not swap as “slot settings” to avoid leaking secrets or environment differences.

Summary:

Through this article, we learned that migrating the .NET in-process Azure Function apps to the isolated model is an essential step as Microsoft plans to retire the in-process model by November 10, 2026. The isolated worker model offers better flexibility, improved runtime isolation, and future compatibility with newer .NET versions.

We also explored the key differences between the two models — how the in-process model runs within the Function host process, while the isolated model runs separately, providing more control and reducing dependency conflicts. Finally, we walked through a detailed, step-by-step migration process that included creating a staging slot, updating the .NET version, and changing the FUNCTIONS_WORKER_RUNTIME from dotnet to dotnet-isolated to complete the transition smoothly.

By following these steps, you can ensure that your Function Apps remain fully supported, secure, and ready for the future of Azure Functions.