An Azure service that provides an event-driven serverless compute platform.
Hi @vasu soni ,
You are asking whether function apps on .NET 8 with the in-process model will keep running until Q1 2027, because the migration analysis will not be finished by the retirement date.
Short answer: they are documented to keep running after the retirement date, but from November 10, 2026 they run without support, and the platform reserves the right to restrict them.
The dates
Support for the in-process model ends on November 10, 2026. The .NET support policy lists the same day as the end of support for .NET 8 itself, so after that date neither the hosting model nor the .NET runtime underneath your apps receives patches.
What happens after November 10, 2026
The Azure Functions language stack support policy describes the retirement phase. Apps on retired versions can still be created and deployed and continue to run on the platform, but they get no new features, security patches, or performance optimizations. The same page states that, where required, Microsoft may limit the number of instances allocated to such apps, including limiting scaling to one instance, and that you must upgrade before receiving support for the app. The page currently lists no exceptions to this policy.
No documented date exists after which in-process apps stop running.
What this means for your timeline
Based on the currently documented retirement behavior, continued operation into Q1 2027 is a reasonable planning assumption, but the documentation does not guarantee it. For the period between November 10 and the end of your migration, plan around these consequences from the policy:
- No security fixes for the retired in-process model or the unsupported .NET 8 runtime.
- A possible instance limit. The policy reserves this measure for cases where it is required; no such limit has been announced. It would matter most for apps that depend on scale-out (high-volume queue, Event Hubs, or Service Bus triggers).
- Support for the app requires upgrading it to a supported version first.
If the analysis cannot be finished for all apps before November 10, my recommendation (a risk assessment of my own, not Microsoft guidance) is to order the migration by exposure: internet-facing HTTP functions and apps that need more than one instance first. The migration guide includes a PowerShell script that lists all in-process apps in a subscription, and it recommends a staging slot so that the switch of FUNCTIONS_WORKER_RUNTIME to dotnet-isolated and the new deployment reach production together in one swap.
Target .NET 10 for the isolated worker model, which is what the migration guide recommends. Moving to .NET 8 isolated would leave you on a runtime that also leaves support on November 10, 2026. I wrote up the path from .NET 8 in-process to .NET 10 isolated, including the build errors that appear during the switch, in Skip .NET 11: your Azure estate belongs on .NET 10.
References
- Migrate C# apps from the in-process model to the isolated worker model
- Azure Functions language stack support policy
- .NET and .NET Core official support policy
- Skip .NET 11: your Azure estate belongs on .NET 10
Drafted with help from Claude, disclosed per the Q&A AI usage policy. All technical claims checked against the Azure Functions documentation on Microsoft Learn and the .NET support policy.