Azure Functions .NET In-Process Retirement (10 Nov 2026): Clarification Needed on Post-Retirement Runtime Availability, Deployments, DR, and SLA Commitments

Rahul Kapoor 0 Reputation points
2026-10-23T15:53:45.64+00:00

Product

Azure Functions

Environment

We currently operate multiple production Azure Function Apps using:

Azure Functions v4

.NET 6

In-process hosting model

Dedicated App Service Plans

App Service Environment (ASE)-hosted workloads

Azure DevOps CI/CD pipelines

Deployment slots and ZIP deployments

Regional disaster recovery procedures

We have reviewed Microsoft's retirement announcement and migration guidance, which state that support for the .NET in-process model ends on 10 November 2026 and that customers should migrate to the isolated worker model. Retirement: Support for the in-process model for .NET apps in Azure Functions ends 10 November 2026 and Migrate C# apps from the in-process model to the isolated worker model.

Documentation Reviewed

Retirement: Support for the in-process model for .NET apps in Azure Functions ends 10 November 2026

Migrate C# apps from the in-process model to the isolated worker model

Business Requirement

We fully understand that Microsoft's recommended and supported path is migration to the isolated worker model. However, large enterprise environments often require extensive testing, dependency validation, security reviews, and phased deployment schedules before migration can be completed.

The current documentation explains that support will end, but it is less clear regarding the practical distinction between:

Unsupported

No longer deployable

No longer functional

Runtime removed from the platform

This distinction is important for long-lived production workloads that may remain operational beyond the retirement date during migration planning and execution.

Questions

1. Runtime Availability After 10 November 2026

Will existing Azure Functions running .NET 6 in-process continue to execute on Azure Functions v4 after 10 November 2026 if no application changes are made?

If so:

Is Microsoft planning to continue hosting the required in-process runtime components indefinitely?

Is there any announced future date on which the runtime itself will be removed from Azure Functions?

2. Deployment Capability

After the retirement date:

Will Azure DevOps pipelines continue to deploy existing .NET 6 in-process applications?

Will GitHub Actions deployments continue to work?

Will ZIP Deploy remain functional?

Will deployment slots and slot swaps remain supported at the platform level?

Will Azure CLI deployments continue to function?

Has Microsoft identified any future point where deployment of existing in-process applications will be blocked or unsupported by platform tooling?

3. Platform Updates and Runtime Stability

For applications that remain unchanged:

Could future Azure Functions host updates cause an existing .NET 6 in-process application to fail startup?

Could App Service platform updates, operating system servicing, or Functions runtime upgrades introduce compatibility issues for workloads that previously operated successfully?

If such risks exist, are there documented support boundaries or mitigation recommendations?

4. Disaster Recovery and Regional Failover

Many organizations rely on DR procedures involving redeployment into another region.

After 10 November 2026:

Will existing in-process applications still be eligible for standard disaster recovery operations?

Will backup/restore scenarios remain supported?

Will regional failover and redeployment scenarios continue to function?

Are there any documented DR limitations specific to unsupported in-process workloads?

5. Azure SLA Applicability

Will Azure Functions and App Service SLA commitments continue to apply to workloads running on the in-process model after support ends?

For example:

If an Azure platform outage impacts an in-process Function App, will Microsoft continue to investigate and remediate the infrastructure issue?

Are there any SLA exclusions that become effective once the application model is unsupported?

6. SDK and Build Tooling

For existing source code targeting .NET 6 in-process:

Does Microsoft expect current build tooling (MSBuild, Azure DevOps agents, Azure Functions SDKs, Azure CLI, deployment tasks, etc.) to remain capable of producing deployable artifacts after 10 November 2026?

Are there any planned deprecations that would prevent customers from rebuilding and redeploying unchanged applications?

What We Are Looking For

We are not seeking migration guidance. We understand that migration to the isolated worker model is the recommended path.

Instead, we are looking for an official statement from the Azure Functions product team regarding:

Runtime availability after support retirement.

Deployment supportability after retirement.

Disaster recovery and regional failover expectations.

SLA applicability.

Long-term platform servicing expectations for existing in-process workloads.

Any product team guidance or official documentation clarifying the difference between unsupported and potentially non-functional would be extremely valuable for enterprise planning and risk assessments.

Thank you.

Product

Azure Functions

Environment

We currently operate multiple production Azure Function Apps using:

Azure Functions v4

.NET 6

In-process hosting model

Dedicated App Service Plans

App Service Environment (ASE)-hosted workloads

Azure DevOps CI/CD pipelines

Deployment slots and ZIP deployments

Regional disaster recovery procedures

We have reviewed Microsoft's retirement announcement and migration guidance, which state that support for the .NET in-process model ends on 10 November 2026 and that customers should migrate to the isolated worker model. Retirement: Support for the in-process model for .NET apps in Azure Functions ends 10 November 2026 and Migrate C# apps from the in-process model to the isolated worker model.

Documentation Reviewed

Retirement: Support for the in-process model for .NET apps in Azure Functions ends 10 November 2026

Migrate C# apps from the in-process model to the isolated worker model

Business Requirement

We fully understand that Microsoft's recommended and supported path is migration to the isolated worker model. However, large enterprise environments often require extensive testing, dependency validation, security reviews, and phased deployment schedules before migration can be completed.

The current documentation explains that support will end, but it is less clear regarding the practical distinction between:

Unsupported

No longer deployable

No longer functional

Runtime removed from the platform

This distinction is important for long-lived production workloads that may remain operational beyond the retirement date during migration planning and execution.

Questions

1. Runtime Availability After 10 November 2026

Will existing Azure Functions running .NET 6 in-process continue to execute on Azure Functions v4 after 10 November 2026 if no application changes are made?

If so:

Is Microsoft planning to continue hosting the required in-process runtime components indefinitely?

Is there any announced future date on which the runtime itself will be removed from Azure Functions?

2. Deployment Capability

After the retirement date:

Will Azure DevOps pipelines continue to deploy existing .NET 6 in-process applications?

Will GitHub Actions deployments continue to work?

Will ZIP Deploy remain functional?

Will deployment slots and slot swaps remain supported at the platform level?

Will Azure CLI deployments continue to function?

Has Microsoft identified any future point where deployment of existing in-process applications will be blocked or unsupported by platform tooling?

3. Platform Updates and Runtime Stability

For applications that remain unchanged:

Could future Azure Functions host updates cause an existing .NET 6 in-process application to fail startup?

Could App Service platform updates, operating system servicing, or Functions runtime upgrades introduce compatibility issues for workloads that previously operated successfully?

If such risks exist, are there documented support boundaries or mitigation recommendations?

4. Disaster Recovery and Regional Failover

Many organizations rely on DR procedures involving redeployment into another region.

After 10 November 2026:

Will existing in-process applications still be eligible for standard disaster recovery operations?

Will backup/restore scenarios remain supported?

Will regional failover and redeployment scenarios continue to function?

Are there any documented DR limitations specific to unsupported in-process workloads?

5. Azure SLA Applicability

Will Azure Functions and App Service SLA commitments continue to apply to workloads running on the in-process model after support ends?

For example:

If an Azure platform outage impacts an in-process Function App, will Microsoft continue to investigate and remediate the infrastructure issue?

Are there any SLA exclusions that become effective once the application model is unsupported?

6. SDK and Build Tooling

For existing source code targeting .NET 6 in-process:

Does Microsoft expect current build tooling (MSBuild, Azure DevOps agents, Azure Functions SDKs, Azure CLI, deployment tasks, etc.) to remain capable of producing deployable artifacts after 10 November 2026?

Are there any planned deprecations that would prevent customers from rebuilding and redeploying unchanged applications?

What We Are Looking For

We are not seeking migration guidance. We understand that migration to the isolated worker model is the recommended path.

Instead, we are looking for an official statement from the Azure Functions product team regarding:

Runtime availability after support retirement.

Deployment supportability after retirement.

Disaster recovery and regional failover expectations.

SLA applicability.

Long-term platform servicing expectations for existing in-process workloads.

Any product team guidance or official documentation clarifying the difference between unsupported and potentially non-functional would be extremely valuable for enterprise planning and risk assessments.

Thank you.

Developer technologies | .NET | .NET Runtime
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-10-23T15:54:36.5333333+00:00

    The documented position is:

    • Support for the Azure Functions .NET in-process model ends on November 10, 2026.
    • The in-process model currently only supports .NET 8 on Functions 4.x.
    • .NET 6 reached end of official support on November 12, 2024.
    • Microsoft recommends migrating to the isolated worker model for continued full support.

    For the specific post-retirement questions:

    • Existing runtime availability after November 10, 2026: the available documentation and accepted Microsoft Q&A content state this is a support retirement, not an immediate runtime shutdown. Apps may continue to run, but the model is out of support.
    • Future removal date of the runtime: no announced future date for runtime removal is provided in the available material.
    • Deployment capability after retirement: no documentation in the available material states that Azure DevOps, GitHub Actions, ZIP deploy, Azure CLI deployments, deployment slots, or slot swaps will be blocked. The accepted Microsoft Q&A content states that deployments may still work but are not guaranteed once the model is unsupported.
    • Platform updates and runtime stability: there is no documented guarantee for long-term compatibility with future platform changes after retirement. The accepted Microsoft Q&A content states Microsoft does not guarantee behavior, compatibility, or issue resolution for unsupported models.
    • Disaster recovery, backup/restore, regional failover: no documented DR-specific limitations for unsupported in-process workloads are provided in the available material.
    • SLA applicability: the available material states the retirement notice does not explicitly change Azure Functions SLA terms, but SLA commitments do not change the fact that the runtime model itself is unsupported.
    • Build tooling and redeployment after retirement: no documented deprecation or blocking of build tooling for unchanged in-process apps is provided in the available material.

    For enterprise risk assessment, the supported distinction available here is:

    • Unsupported = no security updates, no feature updates, and no guaranteed troubleshooting assistance for the in-process model after November 10, 2026.
    • It does not equal an announced immediate shutdown.
    • It also does not include any documented guarantee that apps will remain deployable, compatible, or operational indefinitely.

    A few important version facts for the current estate:

    1. On Functions 4.x, in-process supports only .NET 8.
    2. .NET 6 is already out of official support.
    3. Support for the in-process model itself ends on November 10, 2026.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    1 person found this answer helpful.
  2. Bruce (SqlWork.com) 85,696 Reputation points
    2026-10-24T16:36:06.99+00:00

    Support ends nov 10 2026. Your code will still run, but receive no security fixes. If you have a technical issue, you may not receive support. There has been no official announcement of when hosting will stop. Typically after support ends, Microsoft will announce an end of hosting date.

    Was this answer helpful?

    0 comments
  3. Julian Sharp 46,411 Reputation points
    2026-10-23T16:07:13.5033333+00:00

    Retirement of In-Process model was announced in 2024 giving you two years to migrate to the Isolated Worker model

    https://azure.microsoft.com/en-us/updates?id=retirement-support-for-the-inprocess-model-for-net-apps-in-azure-functions-ends-10-november-2026

    Although your functions may continue to work after November 10th, there are no guarantees and you may not be able to deploy updates. You have not been able to deploy new Functions using .NET 6.0 In-Process models for a while now.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.