Azure Functions .NET 8 vs Future .NET Versions on Isolated Worker — when and how should I migrate?
Choose whether to standardize new Azure Functions apps on .NET 8 in-process for short-term compatibility or move directly to isolated worker to unblock later .NET versions before the November 10, 2026 retirement.
Blockers
- framework/azure-functions-4x-in-process — EOL 2026-11-10
- requires_version: framework/azure-functions-4x-in-process → runtime/dotnet-8
- requires_version: framework/azure-functions-4x-isolated-worker → runtime/dotnet-8
- requires_version: framework/azure-functions-4x-isolated-worker → runtime/dotnet-9
- requires_version: framework/azure-functions-4x-isolated-worker → runtime/dotnet-10
- runtime/dotnet-9 — EOL 2026-11-10
- runtime/dotnet-10 — EOL 2028-11-14
Who this is for
- serverless
- low-ops
- enterprise
Candidates
.NET 8 in-process for short-term compatibility
As of 2026-04-03, the in-process model on Azure Functions 4.x supports only .NET 8 for modern .NET apps, and Microsoft states that in-process support ends on November 10, 2026. That means new apps started on in-process cannot move to .NET 9 or .NET 10 without a later migration to isolated worker. Azure Functions pricing is determined by the hosting plan rather than by in-process versus isolated, so there is no separate in-process price surface to optimize around; check official regional pricing for Consumption, Premium, App Service, and Flex Consumption rates. This path mainly preserves the older programming model for teams that need immediate compatibility with existing in-process libraries or startup patterns.
When to choose
Use this only when short-term compatibility is the overriding constraint and you accept a mandatory migration before November 10, 2026. The decisive factor is whether avoiding migration work now matters more than unlocking later .NET versions and newer Azure Functions features.
Tradeoffs
Least immediate code churn if your team already has in-process conventions, but it creates a second migration later and hard-blocks adoption of .NET 9 and .NET 10.
Cautions
As of 2026-04-03, this option is already on a retirement path. In-process is not supported on Flex Consumption, so you also give up that hosting option while remaining tied to .NET 8 only.
Isolated worker now, standardize on .NET 8 with headroom for .NET 9 and .NET 10
As of 2026-04-03, Azure Functions 4.x isolated worker supports .NET 8, .NET 9, and .NET 10, while Microsoft explicitly recommends upgrading to .NET 8 on isolated worker as the quick path with the longest fully released support window. Microsoft documents .NET 9 support on isolated worker with end of support on November 10, 2026, and .NET 10 LTS on isolated worker with end of support on November 14, 2028. Pricing is still hosting-plan-based rather than process-model-based, but isolated worker supports Flex Consumption, whose pricing page currently shows a monthly free grant of 250,000 executions and 100,000 GB-s for on-demand usage, while classic Consumption shows 1 million executions and 400,000 GB-s. This is the only path that keeps new apps eligible for later .NET versions without another architectural migration.
When to choose
Use this for any new Azure Functions app that should stay fully supported past November 10, 2026 or that may need .NET 9 or .NET 10. The decisive factor is avoiding a dead-end hosting model while keeping the option to choose among supported hosting plans later.
Tradeoffs
You pay migration-style adoption cost up front, but you avoid a forced process-model change later and gain middleware, improved dependency injection patterns, ASP.NET Core integration for HTTP triggers, and Flex Consumption eligibility.
Cautions
Migration from in-process requires code changes: switch `FUNCTIONS_WORKER_RUNTIME` to `dotnet-isolated`, replace `Microsoft.NET.Sdk.Functions` and `Microsoft.Azure.WebJobs.*` dependencies with worker packages, add `Program.cs`, and move startup or logging configuration out of `FunctionsStartup`. If you intend to target .NET 10 on Linux, Microsoft documents that Linux Consumption is not supported for .NET 10 and points you to Flex Consumption instead.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Azure Functions .NET 8 vs Future .NET Versions on Isolated Worker — when and how should I migrate?"