Application Gateway v1 migration has to be finished before April 2026

A lot of the Azure environments I review still have Application Gateway v1 instances tucked away somewhere. Sometimes they front an old test workload, sometimes they sit right in the middle of production. Microsoft has set 28 April 2026 as the retirement date for the Standard and WAF v1 SKUs, so Application Gateway v1 migration is no longer something to get to eventually. It sounds easy enough ("just look for the old gateways"), but in practice v1 gateways are often badly documented and easy to overlook, particularly in tenants that have grown through mergers or years of unplanned sprawl.

A reliable inventory comes first in every v1 migration

Before you can migrate anything, you need a complete list of what exists. Azure Resource Graph is the most dependable tool I know for this. In the Azure portal, open Resource Graph Explorer and run this query to list all Application Gateway v1 instances in every subscription you have read access to:

resources
| where type =~ "microsoft.network/applicationgateways"
| where properties.sku.tier in~ ("Standard","WAF")

As long as you have Reader or Contributor on the subscriptions, the query returns every v1 Application Gateway under your Azure AD tenant. I export the results and go through them with the workload owners. In older environments I also compare the list against legacy documentation and tags, because some gateways turn out to be stopped, renamed or simply forgotten.

Practical tip: Consistent tags ("owner", "env", "criticality") on gateways and their related resources help with more than the Application Gateway v1 migration. They make governance and cost control easier across the board.

Microsoft's Application Gateway v1 retirement announcement has the details, and the v1 to v2 migration guide covers the supported paths.

You can clone the gateway with a script or rebuild it from templates

Microsoft now provides a PowerShell clone script for Application Gateway v1 migration. It reads the configuration of the v1 gateway, creates a new v2 instance and tries to carry over listeners, backend pools and rules. I find it a decent starting point, but I have rarely seen it produce an exact 1:1 copy. Custom health probes, advanced rewrites and hand-built rules almost always need a second look or some cleanup afterwards. If you're planning bigger changes anyway, building the new gateway from scratch in the portal or with ARM or Bicep templates is often clearer and more predictable.

One difference matters a lot: v2 WAF gateways don't store the WAF config on the gateway anymore. Instead, you create a WAF policy and attach it. Moving custom rules and exceptions from the old config into a policy is seldom fully automatic, so set aside time to test the rules with realistic traffic before the cutover. The switch to policy-based WAF is also a good moment to recheck exclusions, update rule sets and add custom logging if you don't have it yet.

Public IPs, certificates and DNS cause the real bottleneck

The public IP change is one of the more disruptive parts of Application Gateway v1 migration. Your new gateway gets a different public IP unless you delete the v1 gateway and immediately reuse its IP for the v2 instance (which means a short outage). So you'll have to coordinate a DNS cutover, and that is always a delicate step for production workloads. I lower the DNS TTL well ahead of time and agree maintenance windows with everyone involved.

The v2 gateway also needs TLS certificates for its HTTPS listeners. I strongly recommend keeping them in Azure Key Vault, which makes automation and rotation much easier. Plenty of older v1 gateways still use certificates uploaded straight to the resource, and the migration is a good opportunity to modernise how you handle keys.

Most migrations stumble over things the scripts don't see

Application Gateway v1 migration is rarely a purely technical job. These are the issues I keep seeing throw supposedly simple projects off track:

• Outdated or missing documentation for custom rules and probes
• Hidden dependencies on legacy networking (NSGs, UDRs, Private Endpoints)
• Undocumented custom scripts or extensions
• WAF exception rules that break after migration
• Inadequate monitoring or alerting during and after cutover

Plan your monitoring before you start, for example with Azure Monitor alerts that catch outages or unusual traffic. A migration is exactly when forgotten dependencies suddenly start to matter. Talk to app owners and end users early, too. Sometimes downtime can't be avoided, but nobody likes being surprised by it.

The migration works best as a governance upgrade

My main recommendation is to use Application Gateway v1 migration to modernise your gateway setup as a whole. Standardise tagging, automate certificate management, review logging and alerting, and put everything into ARM or Bicep templates so you can reuse it later. Good documentation now will spare you a lot of pain at the next audit or when new admins join.

The Mermaid diagram below shows the typical migration process and how the main resources relate to each other. I find it useful to keep at hand while planning and coordinating:

flowchart TD
    v1gw["App Gateway v1"] --> config["Capture config"]
    config --> clone["Migrate/Clone v2"]
    clone --> v2gw["App Gateway v2"]
    v2gw --> certs["Certificates in Key Vault"]
    v2gw --> wafpol["WAF policy setup"]
    v2gw --> publicip["New Public IP"]
    publicip --> dns["DNS cutover"]

Figure: Application Gateway v1 migration from the legacy gateway to v2, with WAF policy, Key Vault and DNS switchover.

If you want more on Azure governance and migration, have a look at my posts on governance in an Azure landing zone and keeping Azure costs under control. The 2026 retirement is confirmed, so the sooner you start mapping and planning, the smoother the migration will go and the less likely you are to end up rushing at the last minute.