Azure VPN Gateway SKU Migration: Move Legacy and Non-AZ SKUs to VpnGw AZ

To move an Azure VPN gateway off a retired SKU, first check which SKU and public IP SKU it uses. Gateways on the legacy Standard or High Performance SKUs, and VpnGw1-5 gateways that still use a Basic public IP, are migrated with the Basic IP migration tool on the gateway's Configuration page, which keeps the address and moves the gateway to VpnGw1AZ-5AZ in the same operation. VpnGw1-5 gateways that already use a Standard public IP are upgraded by selecting the matching AZ SKU, for example VpnGw2 to VpnGw2AZ, which keeps the address and has no expected downtime.

Who this is for and what you will have at the end

This guide is for network engineers who run site-to-site or point-to-site VPN on Azure VPN Gateway and still have gateways whose SKU name doesn't end in AZ, or that show a Basic SKU public IP.

At the end you will have:

• An inventory of every VPN gateway with its SKU, active-active mode and public IP SKU.
• The correct migration path for each gateway.
• Gateways on VpnGw1AZ-5AZ with Standard public IPs and unchanged addresses.
• A validation routine for tunnels, BGP and point-to-site clients before you commit.

Where the deadlines stand

Microsoft's timelines have moved several times; these are the dates on the VPN Gateway documentation as of October 2026.

The backend migration that Microsoft runs from August 2026 happens during off-business hours in the gateway's region, without a per-gateway notification, and isn't reversible. Running the migration yourself is the only way to validate your own traffic before committing.

Which path applies to your gateway

Generation 2 doesn't need a separate migration. The Basic IP migration moves the gateway to Generation 2, and gateways that already use a Standard IP are upgraded to Generation 2 during regular service updates.

Prerequisites

• Rights to modify the gateway, its virtual network, the gateway subnet and its public IPs.
• Azure PowerShell if you prefer cmdlets over the portal; the migration cmdlets are part of Az.Network.
• Gateway subnet size. The migration tool requires at least a /27 GatewaySubnet with at least three free IP addresses in the current prefix. A /28 or smaller subnet fails; add another prefix to the subnet before you start.
• Active-active with point-to-site. A third public IP is required for the P2S endpoint. It must be non-zonal, created with CLI or PowerShell without specifying zones, and attached before you start the migration.
• Active-active with BGP and narrow traffic selectors. Tunnels can stay down after migration. Change the on-premises device to wildcard (0.0.0.0/0) selectors, or make sure it accepts them, before you migrate.
• Point-to-site gateways on legacy cloudapp.net DNS. These need the guided legacy DNS migration and a new VPN client profile.
• ExpressRoute coexistence. Migrate the VPN gateway's Basic IP first; Microsoft states this doesn't affect ExpressRoute traffic.
• Custom routing. List UDRs, load balancers, firewall rules and NVAs that reference the gateway instance private IPs. You update them after the Execute step. If you use VNet peering, keep peering sync enabled during migration.
• A maintenance window and an on-call contact for each on-premises VPN device.

Step 1: Inventory your gateways

Check one gateway from the CLI or PowerShell:

az network vnet-gateway show --name "vpngw-hub" --resource-group "rg-network" --query "sku.name"

(Get-AzVirtualNetworkGateway -Name "vpngw-hub" -ResourceGroupName "rg-network").Sku.Name

To list every VPN gateway you can read across subscriptions, query Resource Graph. The SKU, gateway type and active-active flag are under properties on the gateway resource:

resources
| where type =~ 'microsoft.network/virtualnetworkgateways'
| where properties.gatewayType =~ 'Vpn'
| project
    name,
    resourceGroup,
    subscriptionId,
    location,
    sku = tostring(properties.sku.name),
    activeActive = tostring(properties.activeActive)
| where sku !endswith 'AZ'

For each gateway in the result, open Properties in the portal and select the public IP to see its SKU, or run the Basic public IP query below and match on the IP configuration:

resources
| where type =~ 'microsoft.network/publicipaddresses'
| where sku.name =~ 'Basic'
| where tostring(properties.ipConfiguration.id) contains '/virtualNetworkGateways/'
| project name, resourceGroup, subscriptionId, ipAddress = tostring(properties.ipAddress)

Step 2: Migrate gateways that use a Basic public IP

This applies to VpnGw1-5 and to Standard and High Performance gateways. Don't use it for Basic SKU gateways.

In the Azure portal

1. Open the virtual network gateway. Under Settings, select Configuration, then select Migrate.
2. Review the prerequisites list. If validation fails, fix the reported issues (most often the gateway subnet size) before you continue.
3. Select Prepare. This creates the new Standard public IP resources. It typically takes up to 40 minutes, and at most an hour.
4. Select Migrate. This moves the address to a Standard public IP resource and the gateway to an AZ SKU, for example VpnGw2 to VpnGw2AZ. Expect up to 10 minutes of downtime, and make no changes to the gateway during this step.
5. Select Gateway Validation and check the tunnel ingress and egress graphs on the gateway Overview page. Test BGP, site-to-site and point-to-site traffic.
6. If traffic is wrong, select Abort. The public IP returns to Basic with the same address and the gateway returns to its non-AZ SKU.
7. If traffic is correct, select Commit and Commit changes. Commit typically takes up to 30 minutes, and at most an hour, and deletes the old Basic public IP resource.

The whole process usually takes up to two hours. Commit within a few days; Microsoft advises against leaving a migration pending for long.

With Azure PowerShell

$gateway = Get-AzVirtualNetworkGateway -Name "vpngw-hub" -ResourceGroupName "rg-network"
$migrationParams = New-AzVirtualNetworkGatewayMigrationParameter -MigrationType UpgradeDeploymentToStandardIP
Invoke-AzVirtualNetworkGatewayPrepareMigration -InputObject $gateway -MigrationParameter $migrationParams
 
$gateway = Get-AzVirtualNetworkGateway -Name "vpngw-hub" -ResourceGroupName "rg-network"
Invoke-AzVirtualNetworkGatewayExecuteMigration -InputObject $gateway
 
# after validation
$gateway = Get-AzVirtualNetworkGateway -Name "vpngw-hub" -ResourceGroupName "rg-network"
Invoke-AzVirtualNetworkGatewayCommitMigration -InputObject $gateway
 
# or, to roll back before commit
# Invoke-AzVirtualNetworkGatewayAbortMigration -InputObject $gateway

After the Execute step, update any UDRs, load balancers, firewall rules or NVA configuration that referenced the old gateway instance IPs. Don't change the public IP, gateway, gateway subnet or connections between Execute and Commit, and don't enable DDoS protection until after Commit; concurrent changes can leave the gateway stuck in a state where the only recovery is to delete and re-create it.

Step 3: Upgrade non-AZ gateways that already use a Standard IP

These gateways don't need the migration tool; you change the SKU in place.

1. Open the gateway and select Configuration.
2. In the SKU drop-down, select the AZ SKU of the same tier, for example VpnGw2AZ for a VpnGw2 gateway.
3. Select Save.

The operation takes about 45 minutes. Staying in the same tier has no expected downtime; moving to a different tier at the same time behaves like a normal resize and can cause downtime. With the CLI:

az network vnet-gateway update -g rg-network -n vpngw-hub --sku VpnGw2AZ

The public IP doesn't change and you don't need to reconfigure VPN devices or point-to-site clients. SKUs that support availability zones become zone redundant only in regions with availability zones; elsewhere they stay regional until the region adds zones.

Basic SKU gateways

The Basic gateway SKU isn't retiring, but it's a developer SKU without an SLA and it can't be upgraded. For a Basic SKU gateway that still references a Basic public IP:

1. Open the gateway and select Configuration.
2. Confirm that all resources in the Validation section show Succeeded.
3. Select Delete Basic Public Ip Reference.

The address and connectivity don't change, because Azure already moved the address to an internal Standard public IP. Then delete the leftover Basic public IP resource. Don't try to upgrade that resource to Standard yourself; Microsoft reports that this has left it in a Failed provisioning state. The portal might keep showing the old IP name or an empty value, which is a known display issue.

If you need a supported production gateway, the only route from Basic is to delete it and create a new AZ SKU gateway. That changes the public IP, so you must update on-premises devices, local network gateways on other VNets and point-to-site client profiles.

Verify the migration

• SKU. The gateway Overview page shows an AZ SKU, or az network vnet-gateway show ... --query "sku.name" returns a value ending in AZ.
• Public IP. On Properties, open the IP and confirm the SKU is Standard and the address matches your inventory.
• Tunnels. Check each connection's status and the tunnel ingress and egress graphs.
• BGP. The portal shows new BGP peer IP addresses after an active-active migration. You don't need to change on-premises BGP configuration; Azure redirects traffic from the original peer addresses.
• Point-to-site. Connect a test client. For legacy cloudapp.net gateways, use the profile downloaded after the Prepare step.

Troubleshooting

Migration validation fails on the gateway subnet. The GatewaySubnet is /28 or smaller or has fewer than three free addresses. Add a prefix to the subnet, then retry.

Management operations on the gateway fail with an error. Non-AZ gateways stop accepting configuration changes after the retirement rollout. Migrate to an AZ SKU, then make the change.

Site-to-site tunnels stay down after migrating an active-active gateway. The gateway has BGP and narrow traffic selectors. Switch the on-premises device to wildcard selectors and let the tunnels renegotiate.

Active-active P2S migration fails validation. The third public IP for point-to-site is missing or zone-redundant. Create a non-zonal one and attach it before migrating.

High CPU right after Prepare on a VpnGw1 gateway. Microsoft lists this as a known issue. Wait about 10 minutes after Prepare, or move to a larger SKU during migration.

The gateway is stuck mid-migration. Changes were made between Execute and Commit. Raise a support case; the documented last resort is to delete and re-create the gateway, which changes the address.

Automatic migration of a legacy gateway didn't happen. A constraint such as an undersized gateway subnet blocked it. Fix the constraint and continue the migration from the portal.

Checklist

• Every VPN gateway inventoried with SKU, active-active setting and public IP SKU.
• GatewaySubnet at /27 or larger with at least three free addresses.
• Active-active P2S gateways have a non-zonal third public IP; narrow traffic selectors changed to wildcard where BGP is used.
• Basic IP gateways migrated with Prepare, Migrate, validation and Commit.
• Non-AZ gateways with Standard IPs upgraded to the same-tier AZ SKU.
• UDRs, load balancers, firewalls and NVAs referencing gateway instance IPs updated after Execute.
• Basic SKU gateways have the Basic IP reference removed and the old IP resource deleted.
• SKU, address, tunnels, BGP and P2S verified on every gateway.

Related reading: upgrading other Basic public IPs to Standard and zero trust enterprise remote access architecture.

References

• About VPN Gateway SKU consolidation and migration
• What's new in Azure VPN Gateway?
• Upgrade a VPN Gateway SKU
• VPN Gateway legacy SKUs
• About migrating a Basic SKU public IP address to Standard SKU for VPN Gateway
• How to migrate a Basic SKU public IP address to Standard SKU for VPN Gateway
• Remove the Basic SKU public IP reference from a Basic SKU VPN gateway
• az network vnet-gateway reference
• Virtual Network Gateways - Get (REST API)