.NET 6 and In-process model retirement

Question

We are currently operating Azure Functions based on .NET 6 using the in-process hosting model. While we understand that existing workloads are expected to continue running beyond the announced retirement date, we need clarity regarding the operational and support consequences of this status.

Specifically, are there any documented constraints or edge cases where disaster recovery mechanisms or regional failover might not function as expected for .NET 6 in-process Azure Functions once the in-process model is out of support? After 10 November 2026, will it still be possible to deploy updates to existing .NET in-process functions using standard deployment approaches such as CI/CD pipelines (Azure DevOps or GitHub Actions), ZIP deployment, Azure CLI, or slot swapping?

Additionally, are there circumstances in which existing in-process .NET 6 functions could cease to run or fail during startup without any changes to the application code, for example as a result of underlying platform updates? Are there any planned mandatory migrations following the deprecation date that could affect the availability or runtime behavior of in-process .NET functions?

Finally, after 10 November 2026, will Azure SLA commitments continue to apply to workloads running on the in-process hosting model?

Answer 1

Hi @Miarczynski, Artur

Thank you for reaching out to Microsoft Q&A.

Azure Functions running on .NET 6 using the in‑process hosting model are impacted by a support retirement, not an immediate runtime shutdown. Microsoft has announced that support for the .NET in‑process model ends on 10 November 2026. After this date, applications may continue to run, but the in‑process model will be out of support, meaning it will no longer receive security updates, feature updates, or guaranteed troubleshooting assistance from Microsoft. Additionally, .NET 6 itself has reached the end of its standard support lifecycle, which further impacts long‑term supportability. While there is no documented statement that workloads will stop working automatically, Microsoft does not guarantee behavior, compatibility, or issue resolution for unsupported models, which is why migration is strongly recommended.

Refer below points to resolve this issue or this is the workaround:

Migrate to the isolated worker model (recommended and supported path) Microsoft officially recommends migrating all .NET in‑process Azure Functions to the isolated worker model to remain in a fully supported state beyond 10 November 2026. The isolated model provides runtime isolation, independent .NET versioning, and continued platform support. Documentation: https://learn.microsoft.com/azure/azure-functions/migrate-dotnet-to-isolated-model

Understand post‑retirement support limitations After the retirement date:

• The in‑process model will not receive security or feature updates
• Microsoft support may require reproducing issues on a supported model (isolated worker)
• There are no documented guarantees for long‑term compatibility with future platform changes

Deployments may still work but are not guaranteed Microsoft does not explicitly state that CI/CD, ZIP deploy, Azure CLI, or slot swaps will be blocked after retirement. However, since the model is unsupported, deployment or runtime issues specific to the in‑process model may not be addressed by support. Migrating is the only way to ensure continued deployment reliability and support coverage.

No forced or automatic migration is documented Microsoft has not documented any mandatory or automatic migration of existing in‑process apps. The responsibility to migrate lies with the customer if continued support and reliability are required.

Azure SLA considerations The retirement notice does not explicitly change Azure Functions SLA terms. However, SLA commitments do not override the fact that the runtime model itself is unsupported. Operational SLAs do not imply application‑level support for deprecated runtimes.

In summary, while .NET 6 in‑process Azure Functions may continue running beyond the retirement date, the only supported and future‑proof solution is to migrate to the .NET isolated worker model before 10 November 2026.