Azure Upgrade

Consumption Plan to Flex Consumption Plan Upgrade

Source: Azure Functions Consumption Plan (Y1/Dynamic) on Linux Target: Azure Functions Flex Consumption Plan (FC1/FlexConsumption) Platform: Linux → Linux. For a Windows Consumption source, use the Windows workflow. Docs: Linux migration guide

Why Upgrade?

• Faster cold starts — always-ready instances mean functions respond more quickly

• Better scaling — per-function scaling and concurrency controls

• Virtual network support — connect to private networks and use private endpoints

• Active investment — Flex Consumption is where new features land first

What to Expect

1. Your code stays the same — no rewriting required if on a supported language version

2. You'll create a new app alongside the existing one

3. New app runs in the same resource group with access to the same dependencies

4. You control the timing — test thoroughly before switching over

Platform Notes

• Linux Consumption is being retired September 30, 2028

• Azure CLI provides automated migration commands: az functionapp flex-migration list and az functionapp flex-migration start

• The flex-migration commands handle assessment, app creation, and most configuration migration automatically

• Deployment packages are in squashfs format stored in scm-releases blob container

Prerequisites

• Azure CLI v2.77.0+

• resource-graph extension: az extension add --name resource-graph

• jq tool for JSON processing

• Owner or Contributor role in the resource group

• Permissions to create and manage function apps, storage accounts, App Insights resources, and managed identity role assignments

Compatibility Requirements

Supported Language Stacks

Known Limitations (Flex Consumption)

Upgrade Phases

Phase 1: Assessment

Run all checks from assessment.md. Use the automated eligibility check:

# Automated eligibility check — scans all Linux Consumption apps
az functionapp flex-migration list

This returns eligible_apps and ineligible_apps arrays with specific reasons for any incompatibilities. For detailed manual checks, see automation.md.

Phase 2: Pre-migration (Collect Everything)

Collect all settings and configurations from the existing app before creating the new one. See Step-by-step scripts in automation.md:

1. Collect app settings

2. Collect application configurations (CORS, custom domains, HTTP version, TLS, client certs, etc.)

3. Identify managed identities and RBAC role assignments

4. Identify built-in authentication settings

5. Review inbound access restrictions

6. Get the code deployment package (if source code not in version control)

Phase 3: Create Flex Consumption App

Run the automated migration command from automation.md — Step 4.

The flex-migration start command automatically:

• Assesses your source app for Flex Consumption compatibility

• Creates a new function app in the Flex Consumption plan

• Migrates app settings, identity assignments, storage mounts, CORS, custom domains, and access restrictions

💡 Use Microsoft Entra ID + managed identities instead of connection strings when creating the new app.

Identity-First Configuration (Functions)

Enterprise subscriptions commonly enforce policies blocking local auth. Configure identity-based access:

• Storage accounts: Use AzureWebJobsStorage__credential, __clientId, and service-specific URIs (__blobServiceUri, __queueServiceUri, __tableServiceUri)

• Application Insights: Use APPLICATIONINSIGHTS_AUTHENTICATION_STRING with Authorization=AAD

• When using User Assigned Managed Identity, pass managedIdentityClientId explicitly

Phase 4: Verify and Configure the New App

The flex-migration start command handles most configuration. Verify the results and manually configure anything it doesn't cover (see automation.md):

1. Verify migrated app settings, identities, custom domains

2. Configure built-in authentication (if used — not auto-migrated)

3. Configure scale and concurrency settings (if custom values needed)

4. Enable Application Insights monitoring

Phase 5: Deploy Code

⚠️ Code is NOT automatically migrated. The new app is created with config only — you must deploy code separately.

Use ask_user to present these options:

Your new Flex Consumption app <NEW_APP_NAME> has been created and configured. Now we need to deploy your function code. How would you like to proceed?

1. Update CI/CD pipeline — I'll help you update your Azure Pipelines or GitHub Actions workflow to target the new app

2. Deploy from local project — I'll run func azure functionapp publish <NEW_APP_NAME> from your project directory

3. Deploy existing package — I'll deploy the package we downloaded earlier from the original app

After user selects an option, execute the corresponding deployment method from automation.md — Step 5.

⚠️ After deployment, triggers immediately start processing. Review mitigation strategies for your trigger types.

After successful deployment, inform the user:

Code deployed! Next steps to consider:

• The original app is still running — keep it as rollback for a few days

• Update any clients/pipelines to point to the new URL

• Enable HTTPS-only and managed identity on the new app for better security

• Do not delete the original app until production traffic and every production trigger have completed cutover and target validation

Phase 6: Post-Upgrade Validation

1. Smoke test — Get the app’s default hostname via az functionapp show --query defaultHostName -o tsv, then hit that URL and confirm it returns a non-error response (HTTP 2xx/4xx, not connection refused or 503). This is the minimum bar before proceeding.

2. Verify the app is running on Flex Consumption (az functionapp show --query sku)

3. Test HTTP trigger endpoints (e.g. curl https://<DEFAULT_HOST>/api/<FUNCTION_NAME>)

4. Capture and compare performance benchmarks

5. Set up monitoring dashboards

6. Refine scale/concurrency settings

7. Update IaC (Bicep/Terraform) to reflect new plan

Phase 7: Cleanup (Optional)

• Keep the original app for a few days/weeks as rollback

• Consumption plan charges only for actual usage — low cost to keep idle

• Offer deletion only after all production clients, DNS/custom domains, and triggers use the target; target execution is verified; no production-readiness work remains deferred; and the source no longer processes production workloads

• If any condition is incomplete, retain the source and record cleanup as skipped or deferred

• After every condition passes, use the confirmation and command in automation.md — Step 7

Trigger Migration Risks

IaC Key Differences

Deprecated Settings (Do NOT Migrate)

These app settings are NOT supported in Flex Consumption and should be filtered out:

• WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED

• AzureWebJobsStorage* (replaced by identity-based config)

• WEBSITE_MOUNT_ENABLED

• ENABLE_ORYX_BUILD

• FUNCTIONS_EXTENSION_VERSION (set via functionAppConfig)

• FUNCTIONS_WORKER_RUNTIME (set via functionAppConfig)

• FUNCTIONS_WORKER_RUNTIME_VERSION

• FUNCTIONS_MAX_HTTP_CONCURRENCY

• FUNCTIONS_WORKER_PROCESS_COUNT

• FUNCTIONS_WORKER_DYNAMIC_CONCURRENCY_ENABLED

• SCM_DO_BUILD_DURING_DEPLOYMENT

• WEBSITE_CONTENTAZUREFILECONNECTIONSTRING

• WEBSITE_CONTENTOVERVNET

• WEBSITE_CONTENTSHARE

• WEBSITE_DNS_SERVER

• WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT

• WEBSITE_NODE_DEFAULT_VERSION

• WEBSITE_RUN_FROM_PACKAGE

• WEBSITE_SKIP_CONTENTSHARE_VALIDATION

• WEBSITE_VNET_ROUTE_ALL

• APPLICATIONINSIGHTS_CONNECTION_STRING (already created in new app)

Troubleshooting

Rollback

1. Obtain immediate confirmation, then restart the source app if it was stopped: az functionapp start --name <SOURCE_APP_NAME> --resource-group <SOURCE_RESOURCE_GROUP>

2. Redirect clients back to original resources (queues/topics/containers)

3. Revert DNS or custom domain changes

4. Obtain separate confirmation before deleting the new Flex Consumption app if needed

References

• Flex Consumption plan overview

• How to use the Flex Consumption plan

• Azure CLI flex-migration commands (Linux only)

• Flex Consumption IaC samples

• Flex Consumption plan deprecations