Microsoft Azure Functions has been a popular platform for building serverless applications in .NET using the in-process execution model. However, with the evolution of .NET and the need for greater control, isolation, and long-term support, Microsoft now recommends migrating to the .NET isolated worker model.
In this article, we’ll walk through why this migration is necessary, what drivers make it critical for enterprises, how the in-process and isolated worker models differ, the trade-offs and cost impact, and a practical step-by-step migration approach with code samples based on Microsoft’s official guidance.
Why This Migration Is Necessary
Azure Functions were originally built using an in-process execution model, meaning your function logic ran inside the Functions host process. This architecture had benefits, such as tight coupling with the Azure Functions runtime and automatic binding support. But it also brought limitations, especially when it comes to modern .NET practices.
Microsoft has announced that the in-process model will no longer be supported after November 10, 2026. That makes migration not just recommended — but essential — to ensure ongoing support, security updates, and compatibility with future .NET versions.
Additionally:
The in-process model ties your app directly to the Functions host.
You lose control over runtime versions.
It limits advanced dependency injection and middleware flexibility.
It can limit observability and structured logging.
Driving Factors for Migration
Several key forces are pushing developers and teams toward the isolated worker model:
1. End of Support
Microsoft’s official support lifecycle ends for in-process functions — meaning no updates or security patches after November 2026.
2. Runtime Control
The isolated model runs your function app as its own .NET process, giving you control over:
Host startup behavior
Dependency injection
Logging
Configuration
3. Modern .NET Features
Because the isolated model runs separately, you can adopt the latest .NET features and libraries without risk of runtime conflict.
4. Better Observability
Isolated workers improve structured logging and telemetry, which is especially important for cloud-native applications in production.
Use Cases for the Isolated Worker Model
While all C# functions should migrate eventually, the isolated worker model is ideal for:
Enterprise-level applications: Where observability, startup control, and dependency injection matter.
Microservices architectures: That rely on separation of concerns.
Advanced hosting models: Like Kubernetes via KEDA or containerized deployments.
Apps with complex dependency graphs: That require modern .NET features.
Critical business workloads: Where operational stability and transparency are requirements.
Current (In-Process) vs Target (Isolated Worker)
| Characteristic | In-Process Model | Isolated Worker Model |
|---|
| Execution | Runs inside Functions host | Runs in a separate .NET process |
| Runtime control | Limited | Full control |
| Logging | Less structured | Better structured and configurable |
| Dependency Injection | Limited | Full DI support |
| Dependency conflicts | Possible | Less likely |
| Support beyond 2026 | No | Yes |
| Startup control | Basic | Advanced |
In short, the isolated model gives you the best of modern .NET development practices — with the added benefits of observability and future-proofing.
Trade-Offs and Cost Impacts
Engineering Effort
Migrating is not automatic — code changes are required. Depending on the size of your application and the number of functions, migration can take hours to weeks per app.
Learning Curve
Teams may need time to understand the new startup model and how to manage dependencies, logging, and DI in a new way.
Performance
Because the isolated model runs your logic in a separate .NET process, cold starts may be slightly longer in some cases. But for mission-critical workloads, this is often acceptable and can be mitigated with Premium plans.
Azure Cost
Compute: Slight increase due to additional process overhead.
Monitoring: Potentially more telemetry data.
Hosting: No forced requirement to change plan, but Premium or App Service may be beneficial for performance.
Long-Term Benefit
Despite short-term costs, the long-term benefit of support, control, and maintainability makes migration a sound investment.
Migration Approach – A Step-by-Step Guide
Below is a practical roadmap to take your .NET Azure Functions from in-process to the isolated worker model.
1. Update Project File
Start by editing your .csproj file:
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<OutputType>Exe</OutputType>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.15.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.7.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
</ItemGroup>
Remove all Microsoft.NET.Sdk.Functions and WebJobs references — these are used by the in-process model.
2. Create Program.cs
Replace the legacy FunctionsStartup and host.json-driven startup with a new Program.cs:
using Microsoft.Extensions.Hosting;
var host = new HostBuilder()
.ConfigureFunctionsWorkerDefaults()
.ConfigureServices(services =>
{
services.AddApplicationInsightsTelemetryWorkerService();
})
.Build();
host.Run();
This file is now the entry point for your function app.
3. Update Function Classes
Change your function signatures to match the isolated model:
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;
public class MyFunction
{
private readonly ILogger<MyFunction> _logger;
public MyFunction(ILogger<MyFunction> logger)
{
_logger = logger;
}
[Function("MyHttpTrigger")]
public HttpResponseData Run(
[HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req)
{
_logger.LogInformation("Processing request...");
var response = req.CreateResponse(HttpStatusCode.OK);
response.WriteString("Hello, isolated world!");
return response;
}
}
Notable changes:
Functions are decorated with [Function], not [FunctionName].
Logging uses generic ILogger<T> injected via dependency injection.
4. Update Bindings
Replace binding attributes from WebJobs to the isolated equivalents:
| In-Process | Isolated |
|---|
| [BlobTrigger] | [BlobInput] / [BlobOutput] |
| [QueueTrigger] | [QueueTrigger] (different namespace) |
| [ServiceBusTrigger] | [ServiceBusTrigger] (from Worker package) |
Make sure to reference the appropriate packages:
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
These may require additional NuGet packages.
5. Local Testing
Use the latest Azure Functions Core Tools v4 to test locally:
func start
Verify:
6. Deployment Preparation
Update your Azure Function App configuration:
Set FUNCTIONS_WORKER_RUNTIME to dotnet-isolated.
Deploy using your CI/CD pipeline.
Validate runtime version and app settings.
7. Validate in Azure
Once deployed:
Open the Azure Portal.
Confirm functions are listed.
Trigger them manually or via events.
Check logs in Application Insights.
Wrap-Up
Migration from the in-process model to the isolated worker model represents a strategic shift in how .NET Azure Functions run. It unlocks greater long-term value in terms of supportability, control, and alignment with modern .NET development patterns.
If you plan ahead, use automation, and follow a structured approach like this one, you can complete the migration without risking production stability or team burnout.