Microsoft has set September 30, 2026 as the final cutoff for Azure VPN gateways running the older VpnGw1 through VpnGw5 SKUs—those not backed by availability zones. On that date, any gateway still clinging to the non‑AZ SKU will stop accepting management operations, meaning admins won’t be able to change a tunnel, update a BGP setting, or even tweak a connection without first migrating to the AZ‑capable replacement. The clock started ticking in November 2025 when new deployments of these SKUs were blocked, and now the focus is squarely on existing gateways.

What’s Changing—and When Exactly

The consolidation eliminates five SKUs: VpnGw1, VpnGw2, VpnGw3, VpnGw4, and VpnGw5. Each maps directly to a new counterpart suffixed with “AZ”—VpnGw1AZ through VpnGw5AZ—which adds availability‑zone awareness and, in regions that support it, zonal redundancy. Microsoft began blocking new VpnGw1–5 creations on November 1, 2025. The migration window for existing gateways opened in September 2025 and runs through September 2026, but the precise deadline has shifted. Older documentation once pointed to September 16, 2026; Microsoft’s latest retirement notice and its official Learn guidance now lock the date at September 30, 2026.

The migration itself isn’t just a SKU swap. For gateways already using a Standard public IP address, moving to the same‑tier AZ SKU (e.g., VpnGw2 → VpnGw2AZ) involves no expected downtime. Those gateways will also be seamlessly upgraded to Generation 2 before the deadline through routine service updates, requiring no extra steps from administrators.

Gateways with a Basic public IP add a prerequisite: the Basic IP must first be migrated to Standard using a supported tool. That operation automatically promotes the gateway to Generation 2 and enables the AZ SKU move. Customers who also want to change capacity—stepping up from VpnGw2 to VpnGw3AZ, for example—should expect the usual downtime that accompanies a cross‑family resize; that’s a separate decision from the mandatory retirement remediation.

After the rollout, any gateway left on a VpnGw1–5 SKU will reject configuration changes. Microsoft’s documentation is blunt: “Existing VPN gateways not supported by an availability zone will no longer allow configuration changes. If you attempt any management or configuration operation, you’ll get an error message.” Tunnels may still pass traffic, but an admin trying to adjust a route, renew a certificate, or modify BGP would hit a brick wall until migration completes.

Who’s Affected and What It Means for Operations

The audience is almost entirely network administrators, cloud architects, and DevOps teams managing Azure‑hosted VPN connections. If you’ve never deployed a VpnGw1–5 gateway, this retirement doesn’t touch you. If you have, the impact breaks down into three practical buckets.

Production gateways with compliance or change‑control requirements need a manual, customer‑controlled migration. You’ll want to pick the timing, run pre‑ and post‑validation, and maintain an audit trail. Microsoft’s automatic migration will eventually move these gateways, but it won’t coordinate with your maintenance windows or test your routes.

Lighter, single‑connection gateways may be fine letting Microsoft handle the migration—provided they use a Standard public IP and you’ve confirmed the same‑tier AZ SKU meets capacity needs. Even here, it’s prudent to inventory the gateway and its dependencies first; assuming “it’s simple” is not the same as knowing it’s simple.

Infrastructure‑as‑code definitions that still reference VpnGw1–5 will become drift hazards. A successful portal‑based migration followed by a Terraform or Bicep deployment that tries to revert to the old SKU can break the gateway or cause configuration loops. Every pipeline, ARM template, Azure Policy, and script that names these SKUs must be updated to the AZ equivalents.

The pricing picture shifts, too. New, lower pricing for AZ‑capable SKUs took effect immediately for any gateway already on an AZ SKU. For those still on VpnGw1–5, the reduced rates kick in only after migration is complete. Delaying migration means paying older, potentially higher prices longer than necessary.

The Road to September 30: How We Got Here

Microsoft’s SKU consolidation story began publicly in mid‑2025, framed as a push toward higher availability and lower cost. The VpnGw1–5 lineup lacked native availability‑zone support; customers who wanted zone redundancy had to build their own failover patterns, often paying for extra gateways and managing complex routing. The AZ SKUs bake zone awareness directly into the platform, though the benefit materializes only in regions that support availability zones. Microsoft has been candid that in regions without zone support, the AZ SKU still deploys as a regional resource—the zone‑redundancy capability activates later if the region gains it.

On November 1, 2025, the door closed on new non‑AZ gateway creations. Existing gateways entered a roughly year‑long migration window. The original September 16, 2026 date appeared in some regional mapping documents, but Microsoft’s central guidance now uniformly states September 30, 2026. Administrators who had penciled in the earlier date can take the extra two weeks as buffer, not as reason to delay.

Along the way, the company addressed two adjacent concerns: the Generation 2 transition and the Basic‑to‑Standard IP migration. By tying the Gen2 upgrade to routine service updates for Standard‑IP gateways, and to the public IP migration tool for Basic‑IP gateways, Microsoft removed a separate cutover project from customers’ plates. These moves were designed to let the consolidation advance without forcing every shop to run a distinct generation migration.

Your Migration Roadmap: Concrete Steps to Take Now

Start with a complete inventory. If you have contributor access across subscriptions, Azure Resource Graph is the fastest way to locate affected gateways. A simple query surfaces every VpnGw1–5 instance:

Resources
| where type =~ 'microsoft.network/virtualnetworkgateways'
| extend gatewaySku = tostring(properties.sku.name)
| where gatewaySku in~ ('VpnGw1', 'VpnGw2', 'VpnGw3', 'VpnGw4', 'VpnGw5')
| project subscriptionId, resourceGroup, gatewayName = name, location, gatewaySku

To see the attached public IP SKU—critical for choosing your migration path—expand the IP configuration and join on public IP resources. The query becomes only slightly longer and reveals whether each gateway is on a Basic or Standard public IP.

Once you have the list, tag every row with an owner, a business service, a proposed migration action, and a target date. The public‑IP SKU is the first decision point:

  • Standard public IP, same‑tier move (e.g., VpnGw2 → VpnGw2AZ): This is the cleanest path. You can either wait for Microsoft’s automatic migration (if the gateway is low‑risk and uncomplicated) or schedule a controlled migration yourself. Microsoft says same‑tier, Standard‑IP moves incur no downtime.
  • Basic public IP: You must run the Basic‑to‑Standard migration tool first. That operation also upgrades the gateway to Generation 2. After that, the AZ SKU migration proceeds as above. While Microsoft expects no downtime from the SKU move itself, the IP migration tool’s behavior should be validated in a non‑production environment first.
  • Capacity or SKU‑family change: If you plan to increase capacity (e.g., VpnGw3 to VpnGw4AZ) or move across families, treat the retirement migration as one change event and the resize as another—or combine them intentionally after testing. A resize involves downtime consistent with existing VPN Gateway resize behavior.

For any gateway supporting production workloads, manual migration is the safer default. That gives you control over the maintenance window, the ability to capture pre‑ and post‑migration baselines, and a rollback plan (even if that plan can’t revert to the now‑retired SKU; it might mean failing over to a redundant tunnel).

Before the migration:

  1. Record the current gateway SKU, generation, public IP address, and all connection and BGP settings.
  2. Collect Azure Monitor metrics for tunnel status, bandwidth, and latency at least 24 hours in advance.
  3. Confirm the target region’s availability‑zone support; the “AZ” suffix does not automatically mean the gateway is zone‑redundant.
  4. Update every infrastructure‑as‑code definition, deployment script, Azure Policy assignment, and operational dashboard that references VpnGw1–5.
  5. Schedule the migration in an approved change window, even if Microsoft says no downtime is expected.

After the migration:

  • Validate every site‑to‑site and point‑to‑site tunnel.
  • Confirm BGP peerings, learned routes, and advertised prefixes.
  • Run application‑level connectivity tests from on‑premises to Azure workloads.
  • Keep monitoring elevated for several hours; provisioning success doesn’t guarantee all remote peers are stable.

Monitoring and Post‑Migration Validation

Elevated monitoring should become the norm for at least the first 24 hours after any migration, even one labeled “no downtime.” Track tunnel uptime, dropped packets, and BGP state transitions. If you’re using Azure Monitor, set up temporary alerts on tunnel disconnects or route changes.

Pay special attention to gateways in regions that currently lack availability zones. After migration, your gateway will run on an AZ‑capable SKU but remain a regional deployment. Document that fact for future disaster‑recovery reviews, so no one mistakenly assumes the gateway is zone‑redundant when the region doesn’t yet support it.

Outlook: What Comes Next

As September 30, 2026 approaches, expect Microsoft to increase automatic migration activity. Gateways that haven’t been manually moved will eventually be swept up. But the end of this consolidation is not the end of Azure VPN Gateway changes. Microsoft hasn’t announced a retirement date for Generation 1, but the push toward Generation 2 suggests that further lifecycle shifts are inevitable. The Basic IP migration path will likely be retired eventually as well.

For now, inventory your gateways, pick a migration strategy, and execute before management freezes become an emergency. The teams that act now get to decide whether the transition is a routine, tested network change—or an externally timed service event that happens to their production environment in the middle of the night.