Azure Functions on Container Apps v1 Retires September 2027: Migrate Legacy Apps to v2

That gives teams about a year. It's enough time to migrate without panic, and also enough time to forget about it until next August. Here's what's retiring, how to tell whether it affects you, and what the move to the native "v2" model involves.

First, which "v1" are we talking about?​

Azure Functions has more version numbers than most of us have coffee mugs, so this part matters. The "v1" being retired is not the old Functions runtime, and it isn't the programming model your code is written against. Microsoft's notice says this retirement applies to the Azure Container Apps hosting model, not the programming model version used by your function code.

Microsoft's migration documentation on Learn describes the two ACA deployment models this way:

• Functions v1 (legacy): a legacy proxy model that uses a Function App (Microsoft.Web resource provider) plus a behind-the-scenes container app.
• Functions v2 (native): a native model that creates a single Azure Container App resource (Microsoft.App) with kind=functionapp.

The Azure Functions on Container Apps GitHub repository adds a detail that helps with spotting v1 apps. The legacy model creates an Azure Functions resource that additionally provisions Container Apps resources under a read-only, platform-managed resource group with limited feature access.

Quick way to identify affected apps: If your containerized function app shows up as a Microsoft.Web function app bound to a Container Apps environment, and a locked, platform-managed resource group appeared alongside it, you're on v1. If the function app is a Microsoft.App container app with kind=functionapp, you're already on v2 and can skip ahead.

Summary: This retirement is about where and how the function container is hosted in ACA. Your runtime version and code model aren't what's being retired.

Why Microsoft is pulling the plug​

The v1 model has been living on borrowed time for a while. Microsoft's Learn page for the legacy approach now opens by saying you can host Functions directly in Azure Container Apps by using the Microsoft.App resource provider, and that this article documents the legacy approach that uses the Microsoft.Web resource provider to deploy containerized function apps to a Container Apps environment. The GitHub repo has flagged v1 as supported but not recommended for new projects.

The bigger reason is the feature gap. Microsoft's migration guide says the following aren't available to Functions v1 apps:

• Easy Auth
• Health probes
• Custom domains
• Sidecar containers
• Managed certificates
• Container App secrets
• Granular scale settings
• Multirevision traffic splitting

Troubleshooting is harder too. In a Microsoft Community Hub post on the transition, Microsoft noted that for v1, direct container access and real-time log viewing are not supported. Instead, low-level diagnostics are available via Log Analytics, while application-level logs can be accessed through Application Insights. The same post flags compatibility issues with DAPR with .NET isolated functions, particularly during build processes due to dependency conflicts.

The v2 roadmap is also moving ahead without v1. Microsoft's comparison table lists function listing, keys and invocation counts as planned for v2 and not planned for v1.

Summary: v1 was a stopgap proxy. v2 is a real Container App, and that's where all the new work is going.

The good news: your code probably doesn't change​

Microsoft's migration guide says no code changes are required and that you can reuse your existing container image. That's accurate as far as it goes, but read it carefully. You aren't converting a v1 app in place. You're creating a new v2 resource from the same image and then reapplying your configuration by hand. Settings, secrets, identity, networking and DNS all have to be rebuilt, and that's where migrations usually break.

Microsoft also points to a tool. The retirement notice and the Learn guide both reference the Azure Functions on Azure Container Apps v1 migration assistant for moving apps from v1 to v2. Check what it covers in your environment before you assume it handles everything.

A migration plan based on Microsoft's guide​

This checklist follows the procedure in Microsoft's "Migrate to Azure Functions v2 on Azure Container Apps" documentation.

Prerequisites​

• An Azure subscription and permission to create resources
• The latest Azure CLI, with the containerapp extension (az extension add --name containerapp)
• Access to the container image your v1 app runs
• An inventory of environment variables, secrets, storage bindings and networking settings

One CLI trap from Microsoft's hosting documentation: the containerapp extension conflicts with the appservice-kube extension. If you've published to Azure Arc before, run az extension list. If appservice-kube shows up, remove it with az extension remove -n appservice-kube.

1. Prepare​

1. Confirm the app is a v1 (Microsoft.Web) deployment.
2. Export all configuration: environment variables, secrets, connection strings and custom bindings.
3. Review environment quotas (CPU, memory, max instances).
4. Confirm the image is still in your registry. Rebuilding a lost image a week before the deadline is no fun.

2. Create the v2 app​

Microsoft's guide uses this pattern (replace the placeholders with your own values):

az containerapp create \
  --name my-func-v2 \
  --resource-group <RESOURCE_GROUP_NAME> \
  --environment <ENVIRONMENT_NAME> \
  --image myregistry.azurecr.io/<IMAGE_NAME>:<TAG_NAME> \
  --kind functionapp \
  --ingress external --target-port <TARGET_PORT>

Adjust ingress to fit your workload, because not every function app should be public. Note that legacy containerized function apps listen on port 80 by default unless WEBSITES_PORT was set. Then reapply secrets, environment variables, managed identity and networking, enable authentication or custom domains if you need them, and define scaling rules.

3. Validate​

• Invoke HTTP-triggered functions.
• Test each trigger type you use (Event Hubs, Service Bus, timer and so on).
• Confirm telemetry is reaching Application Insights and Log Analytics.
• Load-test to confirm autoscale rules actually fire.
• Verify secrets and connection strings resolve.
• Check health probe status and revision details.

4. Cut over​

• If you use a custom domain, remap it to the new v2 hostname with a CNAME or A record, rebind TLS certificates, and test resolution and the TLS handshake.
• Shift production traffic. Lowering DNS TTL ahead of time helps.
• Watch latency, errors and invocation counts, and keep a close eye on logs for the first few hours.

5. Clean up​

Decommission the v1 function app and its related resources. Microsoft warns you to first verify that no production traffic still targets the v1 endpoint. Then remove unused secrets and update your runbooks.

Summary: Plan for configuration work and a DNS cutover, not a rewrite. Test triggers and scaling before you touch production traffic.

Don't forget the "unofficial v1.5"​

Some teams skipped both official models and ran a plain container app with a Functions image, without kind=functionapp. Microsoft's migration guide says outright that this approach isn't supported, lacks automatic scale rules, and won't get upcoming v2 features. It isn't named in the retirement notice, but if you're doing this, move to v2 while you're migrating everything else.

Analysis: A generous runway, with a hard cliff at the end​

Credit where it's due: a 12-month notice with a documented migration path and a helper tool is better than some Azure retirements have been. The v2 model is also a real improvement. You get one resource instead of two, native secrets, revisions with traffic splitting for safer rollouts, and live logs for the 2 a.m. incidents.

The catch is in the wording. "Stop running" means triggers stop firing and requests stop being answered. For event-driven workloads, that can mean messages quietly piling up in a queue while nobody notices. The trouble also tends to show up in less obvious places: a timer-triggered job someone set up in 2024, a Service Bus consumer owned by a team that reorganized twice. Inventory now.

This also fits a wider cleanup across Azure Functions hosting. Microsoft's scale-and-hosting documentation notes that function apps still running the end-of-life v3 runtime on Linux in a Consumption plan stop running after September 30, 2026, and that the option to host function apps on Linux in a Consumption plan is retiring on 30 September 2028. If you run a mixed Functions estate, make sure each deadline is tracked separately so the two ACA "v1s" and the runtime deadlines don't get muddled together.

Bottom line​

• What: The legacy Microsoft.Web-based Functions v1 hosting model on Azure Container Apps is being retired.
• When: September 30, 2027. After that, v1 apps stop processing requests and triggers.
• Who: Anyone running containerized function apps in ACA through the legacy model. Your code's runtime version isn't the issue.
• Action: Microsoft says to review your Azure environments and migrate all affected apps to the Functions v2 hosting model before September 30, 2027, to avoid service disruption.

Your container image can stay the same, but your configuration has to be rebuilt on the new resource. Start with the inventory, since it's the step most teams underestimate.