Microsoft’s in-process hosting model for Azure Functions will stop receiving support on November 10, 2026. That gives every team running .NET function apps—whether on .NET 8, .NET 9, or the in-process runtime—a hard deadline to shift to the isolated worker model. The only long-range choice that won’t force another move shortly after is .NET 10, which remains supported through November 14, 2028.

The Support Clock Is Ticking

The change is rooted in a single support policy. On November 10, 2026, Microsoft retires both the in-process model and support for .NET 8 and .NET 9 within Azure Functions. After that date, no security patches or bug fixes will ship for workloads still running on those stacks. The isolated worker model—where your function code runs in a separate process from the Azure Functions host—becomes the only supported path.

Choosing a target .NET version is now a strategic decision. The isolated worker model supports .NET 8, .NET 9, .NET 10, and .NET Framework 4.8. But .NET 9 is a dead end for Azure Functions: its support ends on the exact same day as .NET 8 and in-process. A .NET 8 isolated worker migration can satisfy the immediate retirement requirement, but it also creates another support cliff on that same date. In practical terms, teams that pick .NET 8 today are scheduling a second framework upgrade within the same calendar year. Microsoft’s own guidance treats .NET 10 isolated worker as the preferred long-term destination.

There is one wrinkle. .NET 10 Azure Functions cannot run on the Linux Consumption plan. Organizations on that hosting tier must move to Flex Consumption before they can adopt .NET 10. That adds an infrastructure decision to the migration, not just a code update.

What the Deadline Means for Your Apps

If you own or operate any Azure Functions built on .NET, the first question is simple: are any of them still running in-process? The in-process model is identified by the application setting FUNCTIONS_WORKER_RUNTIME set to dotnet. Isolated worker deployments show dotnet-isolated. A quick inventory will tell you how many apps need attention.

For development teams

The migration is not a configuration-only change. Going from in-process to isolated worker requires code modifications—project files, NuGet packages, function signatures, and often serialization behavior. Durable Functions users face the heaviest lift. Orchestration contexts, client objects, retry policies, and even entity patterns change. Microsoft’s migration guide covers the full API mapping, but the real effort is testing every trigger, binding, and orchestration path. The isolated worker model uses System.Text.Json by default, replacing Newtonsoft.Json. If your functions pass complex objects inside orchestrations, that serialization difference can break without warning.

For IT and operations

Deployment pipelines need a new gate. A production promotion must reject any configuration that still contains FUNCTIONS_WORKER_RUNTIME=dotnet. Slot swaps become critical. The recommended rollout sequence creates a staging slot, deploys the isolated-worker build there, runs named trigger tests, validates telemetry, then swaps to production. A rollback slot with the previous in-process deployment should be retained for an agreed window. For Linux Consumption users, .NET 10 requires a move to Flex Consumption—a separate hosting decision that must be settled before code ships.

For decision-makers

The true cost is not the migration itself, but the risk of letting in-process apps linger. Post-November 2026, unsupported functions could become a security or compliance issue. Starting now means you can sequence migrations without a panic-driven rush. The .NET 10 path buys two additional years of support versus a .NET 8 bridge. For most organizations, that longer runway justifies a slightly larger one-time effort.

How We Got to This Point

Azure Functions launched with an in-process model that tightly coupled your code to the host. It was simple, but it limited control and made it harder to adopt newer .NET features. The isolated worker model arrived as a way to give developers full process isolation, standard dependency injection, and access to the latest .NET runtimes without being blocked by host compatibility.

Microsoft announced the end of in-process support as part of a broader .NET lifecycle alignment. .NET 8 and .NET 9 are short-term support releases, while .NET 10 is a long-term support (LTS) release. By tying the in-process retirement to the end of .NET 8 and 9 support, Microsoft is pushing the ecosystem to an LTS model that they can maintain longer. The company has been signaling this for months. Many WindowsForum discussions noted the practical gap between a published deadline and the real work of locating every in-process app, proving it’s safely migrated, and handling edge cases like Durable Functions or custom serialization.

The pattern isn’t new. Azure AD Graph retirement and .NET Framework-to-core transitions taught us that inventory is the hardest part. Teams often discover dependencies they didn’t know existed only when they try to move.

Your Migration Game Plan

Here’s a repeatable, step-by-step approach that goes beyond a flat checklist.

1. Discover everything

Run an Azure Resource Graph query to list every function app and deployment slot. The query should capture subscription, resource group, name, kind, location, and the netFrameworkVersion property. Then, for each app and each slot, inspect the actual configuration using Azure CLI:

az functionapp config appsettings list --name <app> --resource-group <rg> --subscription <sub> [--slot <slot>]

Record three values: FUNCTIONS_WORKER_RUNTIME, the project’s target framework (from the .csproj or build artifact, not the resource graph), and the hosting plan. Treat every slot as its own deployment.

2. Classify ruthlessly

  • FUNCTIONS_WORKER_RUNTIME=dotnet → In-process migration candidate.
  • FUNCTIONS_WORKER_RUNTIME=dotnet-isolated → Already on isolated worker; still needs framework and plan review.
  • Any missing or unexpected value → Investigate the deployment before labeling it compliant.

Build a migration queue. Prioritize production-facing in-process apps, apps with no identified owner, and any Durable Functions workload. An “owner unknown” record should jump to the top—no migration plan is credible without someone responsible for testing and rollback.

3. Pick your target framework

  • Default choice: .NET 10 isolated worker. It gives the longest support (through Nov 2028) and is the cleanest one-and-done migration. Use it unless you have a concrete blocker.
  • Bridge choice: .NET 8 isolated worker. Accept this only when a dependency, release freeze, Durable Functions conversion complexity, or Linux Consumption constraint makes a direct .NET 10 move unsafe. Document the exception with an owner and a reevaluation date before November 10, 2026.
  • Never choose .NET 9. Its support ends on the same retirement day, adding zero runway.

4. Migrate the code

For standard HTTP triggers and simple bindings, updating packages and adjusting function signatures is straightforward. Durable Functions require a methodical rewrite:

  • Replace IDurableOrchestrationContext with TaskOrchestrationContext.
  • Replace IDurableOrchestrationClient with DurableTaskClient.
  • Change StartNewAsync to ScheduleNewOrchestrationInstanceAsync.
  • Entity functions move from a single static method with a switch statement to a class-based dispatcher pattern.
  • Remove all Microsoft.Azure.WebJobs.* packages and replace them with Microsoft.Azure.Functions.Worker.* equivalents.
  • Add a Program.cs entry point. If you had a FunctionsStartup class, move those registrations into ConfigureServices.

Test locally with func start. Run named trigger tests: invoke HTTP endpoints, submit queue messages, fire timer equivalents, and validate output destinations. For Durable Functions, test orchestration start, activity completion, state progression, failure handling, and status endpoints.

5. Validate telemetry and cut over

After deploying to a non-production slot, confirm that FUNCTIONS_WORKER_RUNTIME is dotnet-isolated and the framework matches your approved record. Execute the same trigger tests and inspect Application Insights to ensure successful executions, dependency tracking, and error visibility are intact.

Cut over to production via a slot swap. Keep the prior deployment for the agreed rollback window. If a named trigger test fails, expected telemetry is missing, or business output doesn’t match, revert immediately.

6. Block regressions

Add a deployment gate that rejects any production promotion containing FUNCTIONS_WORKER_RUNTIME=dotnet. The gate should also flag a mismatch between the approved framework, worker runtime, and hosting plan (e.g., a .NET 10 isolated-worker release targeting Linux Consumption).

Every approved .NET 8 exception must name its owner, list the blocking dependency or constraint, and include a reevaluation date before the final deadline.

What Comes Next

The November 2026 deadline isn’t a surprise, but it will catch organizations that haven’t started inventorying their function estate. The conversation on WindowsForum shows that many teams are already building structured migration queues and using slot swaps as their operational safety net. Microsoft’s tooling may improve—expect more Azure Portal guidance and perhaps automated discovery as the date nears—but the fundamental task remains the same: find every in-process app, pick a framework, convert code carefully, and prove it works before swapping. The teams that start now will treat this as a routine platform refresh, not a fire drill.