Andrzej Kaczmarek Infrastructure & Cloud Architect
← All posts
azurenetworkingwafmigration

Application Gateway v1 is retired: a migration runbook for the stragglers

Application Gateway v1 retired on 28 April 2026 and Microsoft is now decommissioning the hardware and deleting unmigrated gateways. Here is a concrete runbook to find any v1 you still have, clone it to v2, cut traffic over, and fix the WAF on the way out.

· 6 min read

You open a subscription you don’t touch often, run a quick inventory, and there it is: an Application Gateway still on the v1 SKU. The deadline to migrate was 28 April 2026 — it has already passed. If that’s you, don’t panic, but don’t sit on it either. Migration is still self-serve today, and that’s a much better place to be than waiting for the deletion notice. Here’s the runbook I’d work through.

What “retired” actually means now

Microsoft announced the v1 deprecation back on 28 April 2023 and retired the SKU exactly three years later, on 28 April 2026. Retired isn’t a soft state:

  • There’s no SLA, no patches, and no support for v1 resources anymore.
  • As Microsoft decommissions the underlying hardware (the “scream tests”), traffic through v1 gateways can no longer be guaranteed.
  • Microsoft has said it will announce a deletion timeline, then block the data path and delete the v1 deployments that haven’t been migrated.

Two things to internalise before you start. First, Microsoft will not migrate your data for you — v1 is built on legacy components and every deployment is a little different, so this is on you. Second, for anything non-trivial, plan for the migration to take up to a couple of months. This is not a Friday-afternoon job.

Step 1 — Find every v1 gateway you still have

You can’t migrate what you haven’t inventoried, and v1 gateways love to hide in old subscriptions. Azure Resource Graph answers this across your whole tenant in one query. v1 gateways carry a SKU tier of Standard or WAF; v2 uses Standard_v2 / WAF_v2:

Resources
| where type =~ 'microsoft.network/applicationgateways'
| where properties.sku.tier in~ ('Standard', 'WAF')   // v1 tiers only
| project name, resourceGroup, subscriptionId, location,
          tier = tostring(properties.sku.tier),
          sku  = tostring(properties.sku.name)
| order by subscriptionId asc

Run it in Resource Graph Explorer in the portal or with az graph query -q "<query>". Anything that comes back is a migration item.

Step 2 — Understand the two stages

Migration has two distinct stages, and the tooling only covers the first one:

  1. Configuration migration — clone the v1 settings onto a brand-new v2 gateway.
  2. Traffic migration — cut your clients over to that v2 gateway.

The PowerShell scripts Microsoft ships only migrate the configuration. Moving live traffic is a separate, deliberate step that you own. Keep the two stages clearly apart in your change plan.

Step 3 — Clone the configuration

Microsoft publishes the cloning scripts on the PowerShell Gallery. The enhanced cloning script (AzureAppGWClone) is the recommended one — it copies your TLS/SSL and trusted root certificates automatically, supports private-only v2 gateways, and can build a WAF policy for you in the same pass.

# From Azure Cloud Shell, or a local session with the Az modules.
# Run Set-AzContext FIRST, every single time — if the script runs against the wrong
# subscription context it can clean up the existing resource group.
Set-AzContext -Subscription '<v1-subscription-id>'

Install-Script -Name AzureAppGWClone -Force

./AzureAppGWClone.ps1 `
  -resourceId '/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/applicationGateways/<v1-name>' `
  -subnetAddressRange '10.0.1.0/24' `   # a NEW subnet — v1 and v2 can't share one
  -appgwName 'appgw-prod-v2' `
  -wafpolicyname 'waf-prod-policy'      # builds a WAF policy from the v1 WAF config

A few things worth knowing:

  • The script takes roughly five to seven minutes.
  • v1 and v2 cannot live in the same subnet, so you must hand it a new address range (CIDR) in the same virtual network with enough free IPs.
  • It creates the v2 gateway with a size appropriate to your v1 traffic. Set autoscale explicitly and verify it afterwards rather than assuming a default — the enhanced script exposes -DisableAutoscale, the legacy AzureAppGWMigration script defaults autoscale off and takes -enableAutoScale.

When it finishes, test the v2 gateway directly — send a little traffic to its own IP and confirm the data path works — before you touch anything customer-facing.

Step 4 — Cut the traffic over

Two common approaches, depending on how much downtime you can absorb.

Public IP retention (AzureAppGWIPMigrate) reserves the public IP from v1, converts it from Basic to Standard, and attaches it to v2 — so clients hitting that IP just land on v2:

Install-Script -Name AzureAppGWIPMigrate -Force

./AzureAppGWIPMigrate.ps1 `
  -v1resourceId '<v1-resource-id>' `
  -v2resourceId '<v2-resource-id>'

This is the quick path, with a brief ~1–5 minute downtime. Caveats: v1 and v2 must be in the same subscription, the swap is irreversible, and the script won’t touch a public IP whose DNS name starts with a digit (common on v1 gateways created before May 2023, which got an auto-assigned {GUID}.cloudapp.net label) — rename the label first.

If you’d rather bleed traffic over gradually, keep both gateways running and use DNS — repoint your A record, or put both behind an Azure Traffic Manager profile with weighted routing and shift the weights over time. Slower, but fully controlled and reversible.

Step 5 — Don’t stop at v2: fix the WAF

If you were running WAF v1, migrating to v2 is only half the job. v1 has no concept of a WAF policy, so a freshly migrated gateway lands on legacy WAF configuration — and that mode is itself on the way out. Microsoft announced its deprecation in 2024, blocked new WAF-configuration deployments on 15 March 2025, and retires it entirely on 15 March 2027. Migrating onto a dead-end config helps nobody.

So go straight to a WAF policy. Either pass -wafpolicyname to the clone script in Step 3, or upgrade an existing legacy configuration afterwards — in the portal it’s Web Application Firewall → Upgrade from WAF configuration, and it’s a no-downtime operation (also available via Firewall Manager or PowerShell). While you’re there, note that the migrated WAF v2 defaults to CRS 3.0, which is on the deprecation path — move to the latest DRS rule set once you’re stable.

The gotchas the script won’t fix for you

  • Diagnostic settings aren’t replicated. If your v1 gateway shipped logs to a Storage account or Log Analytics, the clone does not carry that over — re-add it on v2.
  • Backend TLS got stricter. v2 validates the full certificate chain and subject name by default, where v1 did an exact-match on an authentication certificate. The enhanced script relaxes that validation during the clone so you don’t break on day one — treat that as temporary and re-enable full validation for production.
  • FIPS mode is not migrated.
  • NSG/UDR on the new subnet must meet Application Gateway’s requirements, or the deployment fails.
  • New IPs by default — unless you use the IP-retention script or attach an existing unallocated IP, v2 comes up with fresh public and private addresses.

The takeaway

The deadline has passed, but the door hasn’t closed: migration is still self-serve, and the scripts do most of the heavy lifting. The risk isn’t the migration — it’s the deletion notice arriving before you’ve started. Inventory your v1 gateways this week, clone the busiest one into a v2 with a real WAF policy, and rehearse the IP cutover in a maintenance window. Future-you, reading the “your gateway will be deleted” email, will be glad it’s already a non-event.

Sources & further reading: Migrate from Application Gateway V1 to V2 by April 28, 2026, FAQ about Application Gateway V1 retirement, Migrate Application Gateway and WAF from V1 to V2, Upgrade to Azure Application Gateway WAF policy.