Azure Functions: in-process .NET, .NET 8 and PowerShell 7.4 support all end on 10 November

Several Azure Functions support dates fall on Tuesday 10 November 2026. Microsoft’s migration guide opens with it: “Support for the in-process model ends on November 10, 2026. Migrate your apps to the isolated worker model.”

What ends on 10 November

The Functions language support table lists these dates:

• In-process model. Support ends on 10 November. The in-process model only supports .NET 8, and .NET 10 isn’t supported in-process, so there is no newer .NET to move to without changing models.
• .NET 8 and .NET 9 on the isolated model. Both have an expected end-of-support date of 10 November too. Moving to isolated but staying on .NET 8 doesn’t buy any time. .NET 10 is supported until 14 November 2028.
• PowerShell 7.4. Also 10 November. PowerShell 7.6 is supported until 14 November 2028.

These dates follow the .NET support policy, which lists .NET 8 and .NET 9 as in maintenance with end of support on 10 November 2026. After that, Microsoft stops providing fixes and updates for them, and says using out-of-support versions “may put your applications, application data, and computing environment at risk.”

Microsoft’s pages announce the end of support. They don’t say that in-process apps stop running on 10 November, and we make no claim either way. They do say that continued full support needs the isolated worker model.

Linux Consumption apps need a plan change first

.NET 9 is the last .NET version added to Linux Consumption apps, and Microsoft’s class library guide says .NET 10 apps can’t run on Linux in the Consumption plan. PowerShell 7.4 is likewise the last version there: before upgrading such an app to 7.6 you must first move it to the Flex Consumption plan. Windows Consumption, Premium, Dedicated and Flex Consumption plans support PowerShell 7.6.

How the migration goes

The guide covers the steps in detail. The parts most likely to catch teams out:

• Finding apps. Microsoft gives a short Azure PowerShell script that lists function apps in a subscription whose runtime is dotnet, meaning in-process.
• Target. Use .NET 10 if your app and its dependencies run on modern .NET, or .NET Framework 4.8 if you depend on Framework-only APIs.
• Two changes, one restart window. You set FUNCTIONS_WORKER_RUNTIME to dotnet-isolated and publish the migrated project. Between the two, the app throws a runtime and payload mismatch error (AZFD0013). Microsoft recommends doing both in a staging slot, then swapping.
• Silent JSON changes. The isolated model uses System.Text.Json by default. It ignores Newtonsoft attributes such as [JsonProperty] and [JsonIgnore] and binds the property to its default value “without reporting an error.”
• Synchronous HTTP I/O. With ASP.NET Core integration, synchronous stream reads and writes can fail with InvalidOperationException. Switch to the async methods.
• Logging. host.json now only controls logs from the Functions host. Filtering for your own code moves into Program.cs.

The JSON item is the kind of change that compiles cleanly and still breaks behaviour, a pattern we covered in Cargo.lock, SemVer and the update that broke your build. And the risk of staying put is the same one AWS spelled out for its end-of-life Multi Model Server: once support ends, a new flaw doesn’t get a fix.

Why this matters

If you run C# function apps, check each app’s FUNCTIONS_WORKER_RUNTIME setting and target framework this week. Anything on dotnet (in-process), or on dotnet-isolated with .NET 8 or 9, should move to .NET 10 isolated, and Linux Consumption apps need a Flex Consumption move first. Search your bound types for Newtonsoft attributes before you deploy, because those failures don’t raise an error.