Subchapter 42.41
references/services/functions/consumption-to-flex/windows/automation/networking-and-storage.mdMarkdown4 KBView on GitHub
az functionapp cors show --name <SOURCE_APP_NAME> --resource-group <SOURCE_RESOURCE_GROUP> --query allowedOrigins -o tsvAdd each origin to the new app (repeat per origin):
az functionapp cors add --name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP> --allowed-origins <ORIGIN>List custom domains on the source app (excluding the default *.azurewebsites.net):
az functionapp config hostname list --webapp-name <SOURCE_APP_NAME> --resource-group <SOURCE_RESOURCE_GROUP> --query "[?!contains(name, 'azurewebsites.net')].name" -o tsvAdding a hostname binding does not update its DNS record or move traffic to the target. Verify domain ownership as described in Migrate an active DNS name (opens in a new tab), then attempt to add each domain to the new app (repeat per domain):
az functionapp config hostname add --webapp-name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP> --hostname <CUSTOM_DOMAIN>If Azure rejects the binding because the hostname cannot be assigned to both apps, stop and record custom-domain migration as deferred. Do not remove the source binding, change DNS, or alter its certificate during this replication phase.
Get access restrictions from the source app:
az functionapp config access-restriction show --name <SOURCE_APP_NAME> --resource-group <SOURCE_RESOURCE_GROUP> -o jsonFor Blob/Event Grid triggers, first check the target’s public network access and the complete proposed main-site rule set, including fallback actions, against the Event Grid delivery path agreed in Step 2f. Event Grid push delivery cannot reach a private-only endpoint; outbound VNet integration does not resolve this. If the configuration cannot be read or the proposed restrictions would block delivery, stop and record Step 4i as blocked. Use ask_user to resolve the delivery design; do not automatically enable public access or relax restrictions.
Recreate every explicit main-site rule, preserving its name, action, priority, description, and selector. Skip platform-generated fallback rows with priority 2147483647 (Allow all or Deny all); default actions are applied separately below.
az functionapp config access-restriction add --name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP> --rule-name <RULE_NAME> --action <Allow|Deny> --priority <PRIORITY> --description "<DESCRIPTION>" --ip-address <IP_CIDR>Use exactly one selector matching the source rule:
--ip-address <IP_CIDR>--service-tag <SERVICE_TAG>--subnet <SUBNET_RESOURCE_ID>If the source has explicit SCM rules and scmIpSecurityRestrictionsUseMain is false, recreate them with the same command plus --scm-site true.
After all explicit rules are present, apply the captured fallback behavior. Set default actions last so the target remains reachable while rules are being added:
az functionapp config access-restriction set --name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP> --default-action <MAIN_DEFAULT_ACTION> --scm-default-action <SCM_DEFAULT_ACTION> --use-same-restrictions-for-scm-site <true|false>⚠️ Skill instruction: Before setting a default action to
Deny, verify that an explicit allow rule covers the user’s smoke-test client and that required deployment traffic can still reach SCM. Useask_userto list the rules and fallback actions being applied. Do not migrate platform-generated fallback rows as ordinary rules.
Verify actions, priorities, selectors, descriptions, default actions, and SCM behavior:
az functionapp config access-restriction show --name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP> -o json