VPN Gateway Basic IP migration: check and validate

What changed

Microsoft shipped a migration path, in the portal and in PowerShell, that moves a VPN gateway from a Basic to a Standard public IP without changing the IP address. It covers VpnGw1–5 and the legacy Standard and High-Performance gateway SKUs, in both active-standby and active-active mode.

That self-service window has now closed. Microsoft is running the same migration on the back end for anything left, so the question is no longer “when do we migrate?” but “has it happened, and does everything still work?”

What the migration changes:

• The Basic public IP resource becomes Standard. The IP address stays the same.
• VpnGw1–5 become VpnGw1AZ–5AZ. Expect IaC drift on the SKU.
• On active-active gateways, the portal shows new BGP peer IPs. Microsoft says existing on-premises BGP configuration keeps working without changes, because traffic to the old peer IPs is redirected.
• Gateway instance private IPs can change. Anything you built that points at them needs checking.

Who is impacted

You should care if any of these are true:

• You run Azure VPN Gateways on VpnGw1–5 or a legacy gateway SKU
• Any of them still had a Basic SKU public IP after 31 July 2026
• You rely on the gateway for critical connectivity (on-prem, partners, branch sites)
• You use one of the configurations Microsoft lists as known to be affected (below)
• You have automation that assumes the old SKU names or IP resource shapes

Basic SKU gateways are different. A Basic gateway SKU with a Basic public IP reference doesn’t go through migration. You remove the Basic public IP reference and the gateway keeps the same address.

Configurations known to be affected

Microsoft lists these as needing customer action, with possible connectivity impact if they aren’t remediated before a back-end migration:

• Custom (narrow) traffic selectors. On active-active gateways with BGP, tunnels can stay down after migration. Microsoft’s fix is to move the on-premises device to wildcard (0.0.0.0/0) selectors, or make sure it accepts them.
• Active-active with point-to-site (P2S) VPN. Needs a third public IP (see prerequisites).
• CloudApp-based P2S, where the client profile FQDN ends in cloudapp.net. These use a guided migration and need an updated VPN client profile.
• Remote RADIUS authentication for P2S.

If you run any of these and the gateway has already been migrated by Microsoft, test that path first.

Why it matters

• SLA: an un-migrated gateway has had no VPN Gateway SLA since 30 June 2026.
• Control: a Microsoft-initiated migration happens without notice and can’t be rolled back. Your validation is all that’s left.
• Drift: the SKU change and the new Standard IP resource put your IaC out of step with reality.
• Platform consistency: standardising IP SKUs and gateway patterns makes landing-zone networking guardrails easier.

Find any Basic public IPs still in the estate with Azure Resource Graph:

resources
| where type =~ 'microsoft.network/publicipaddresses'
| where tostring(sku.name) =~ 'Basic'
| project subscriptionId, resourceGroup, name,
          attachedTo = tostring(properties.ipConfiguration.id)
| order by subscriptionId asc

Then list your VPN gateways and their SKUs. An AZ suffix after the migration window is a good sign the gateway has moved. A non-AZ VpnGw1–5 SKU with a Basic IP attached means it hasn’t yet.

resources
| where type =~ 'microsoft.network/virtualnetworkgateways'
| where tostring(properties.gatewayType) =~ 'Vpn'
| project subscriptionId, resourceGroup, name, location,
          sku = tostring(properties.sku.name),
          activeActive = tobool(properties.activeActive),
          bgp = tobool(properties.enableBgp)
| order by subscriptionId asc

Runbook: confirm the migration, then validate

Success criteria

Comms template for stakeholders