VpnGw1 to VpnGw1AZ migration repeatedly fails

Hello @Matt Carson

Based on the configuration you've described, I don't see an obvious prerequisite issue that would explain the migration failure.

A VpnGw1 → VpnGw1AZ migration is part of Microsoft's current VPN Gateway SKU consolidation, and having a Standard SKU public IP already in place is important. Your /24 GatewaySubnet also shouldn't itself prevent the migration. Microsoft currently recommends manually upgrading non-AZ VpnGw1-5 gateways to their AZ equivalents during the migration period.

Since the existing S2S connection remains operational and the migration repeatedly fails specifically during preflight/deployment validation, I'd first capture the actual failure returned by Azure rather than modifying the working VPN configuration.

Please check the Activity Log on MTCloudVPN immediately after another failed attempt and look for the failed Microsoft.Network/virtualNetworkGateways operation. Expand the JSON/error details and capture:

error.code

error.message

correlationId

operationId

timestamp

I would also verify the current gateway state from CLI:

az network vnet-gateway show \
  --resource-group <resource-group> \
  --name MTCloudVPN \
  --query "{sku:sku.name,generation:generation,provisioningState:provisioningState,activeActive:activeActive,ipConfigurations:ipConfigurations[].publicIPAddress.id}"

and confirm the public IP:

az network public-ip show \
  --resource-group <resource-group> \
  --name <public-ip-name> \
  --query "{sku:sku.name,tier:sku.tier,allocation:publicIPAllocationMethod,zones:zones}"

One thing I wouldn't do yet is delete/recreate the gateway or S2S connection. Microsoft states that same-family migration from a non-AZ SKU to its AZ counterpart isn't expected to cause downtime, so a repeatable preflight failure on an otherwise healthy gateway deserves investigation before rebuilding anything.

If the Activity Log doesn't expose a customer-correctable validation error, then I agree this should be escalated to Microsoft. The networking team can inspect the backend migration eligibility/state using the correlation and operation IDs.

Sharing these references with you:

VPN Gateway SKU consolidation and migration

Reliability in Azure Virtual Network Gateways

Matt, if you can post the error code/message from the failed Activity Log operation (with subscription/resource identifiers removed), we may be able to narrow down the blocker before escalation.

@Microsoft Moderator, Bharath Y P, could you please help review this gateway's backend migration state/eligibility if Matt provides the failed operation details?

Please "Accept the Answer" if this information helped you. This will help us and others in the community.