Migrating .NET 6 Azure Functions from In-Process to .NET 8 Isolated Worker Model

Why Migrate to the Isolated Worker Model?

Retirement: Support for the in-process model for .NET apps in Azure Functions ends 10 November 2026.

The in-process model, while convenient, binds your code closely to the Azure Functions runtime. This can introduce limitations, especially with version conflicts and testing complexities. The isolated worker model offers more freedom by decoupling the function app's execution from the runtime, allowing for:

• Independent updates: You can update your app without worrying about Azure Functions runtime updates.
• Better testing: The isolated model makes it easier to write unit tests without depending on the runtime.
• Custom middlewares: It introduces the ability to use custom middlewares, enhancing extensibility.

Step-by-Step Migration Process

1. Upgrade to .NET 8

To begin, ensure that your Azure Function project is upgraded to .NET 8. You can do this by modifying the TargetFramework in your .csproj file:

If you're still on .NET 6, I recommend using the .NET Upgrade Assistant to streamline the process. This tool is a great starting point for upgrading across different .NET versions.

2. Install the Required Packages

Next, install the necessary NuGet packages for the isolated worker model. Replace any existing in-process dependencies with the isolated worker equivalents:

dotnet add package Microsoft.Azure.Functions.Worker
dotnet add package Microsoft.Azure.Functions.Worker.Sdk        

These packages provide the essential support for building function apps in the isolated model.

3. Configure the local.settings.json & host.json File

Update your host.json file to support the isolated worker model:

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[3.*, 4.0.0)"
  }
}        

This ensures compatibility with the latest Azure Functions extension bundles.

4. Migrate Function Definitions

In the isolated worker model, the function signatures change slightly. You'll need to update your function methods to use FunctionContext instead of HttpRequestData for HTTP-triggered functions, for example.

Here's a sample migration of an HTTP-triggered function:

Before (In-Process Model):

public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req, 
    ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");
    return new OkObjectResult("Hello, World!");
}        

After (Isolated Worker Model):

public class MyFunction
{
    private readonly ILogger<MyFunction> _logger;

    public MyFunction(ILogger<MyFunction> logger)
    {
        _logger = logger;
    }

    [Function("MyFunction")]
    public async Task<HttpResponseData> Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req, FunctionContext context)
    {
        _logger.LogInformation("C# isolated worker function processed a request.");
        var response = req.CreateResponse(HttpStatusCode.OK);
        await response.WriteStringAsync("Hello, World!");
        return response;
    }
}        

Notice how the isolated worker model promotes dependency injection, which makes it easier to test and maintain functions.

5. Update Program.cs

The isolated worker model uses a more familiar Program.cs setup, similar to ASP.NET Core applications. Here's how to configure it:

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

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .Build();

host.Run();        

6. Use .NET Upgrade Assistant for Extensions

During migration, if your function app relies on Azure Functions extensions, such as Azure Storage or Cosmos DB bindings, you can use the .NET Upgrade Assistant to identify and suggest the necessary upgrade paths.

Run the upgrade assistant with the following command:

dotnet upgrade-assistant upgrade        

The tool will automatically detect the usage of deprecated in-process extensions and recommend isolated worker equivalents. This is a great way to avoid manual extension mapping, ensuring that your project is updated with the latest and compatible bindings for the isolated worker model.

Benefits of the Isolated Worker Model in .NET 8

• Performance: With better resource isolation, function apps can achieve higher performance and scalability.
• Simplified Testing: Unit tests become more straightforward as your function logic is independent of the Azure Functions runtime.
• Extended Middleware Support: The isolated worker model introduces middleware, allowing developers to build custom request pipelines, similar to ASP.NET Core.
• Future-Proofing: Migrating now prepares your application for future innovations in the Azure Functions ecosystem.

Wrapping Up

Migrating to the .NET 8 isolated worker model enhances the modularity, testability, and maintainability of your Azure Functions. With the support of tools like .NET Upgrade Assistant, you can upgrade existing projects more efficiently, ensuring that you're leveraging the latest features of the platform.

As you plan your migration, consider these best practices to minimize downtime and ensure a smooth transition. Embrace the isolated worker model now to future-proof your applications and unlock the full potential of serverless computing on Azure.

Additionally, I have included some useful links below for your reference:

Guide for running C# Azure Functions in an isolated worker process | Microsoft Learn

https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-in-process-differences#execution-model-comparison-table

https://learn.microsoft.com/en-us/dotnet/core/porting/upgrade-assistant-install