Azure VPN Gateway customers should manually move critical, tightly governed, or architecturally changing networks from VpnGw1–VpnGw5 to the corresponding AZ SKU rather than waiting for Microsoft’s automatic migration. Automatic migration is reasonable for straightforward Standard-public-IP gateways where the goal is simply preserving the existing tier, but it should not become a substitute for inventory, dependency testing, or change control.
Microsoft’s current Azure VPN Gateway documentation places the consolidation through September 2026, while its latest retirement notices identify September 30, 2026 as the deadline. The previously circulated September 16 date appears in older regional documentation and should no longer be treated as the controlling date unless Microsoft changes its guidance again.
The practical question is therefore not whether the non-AZ SKUs are leaving. It is whether Microsoft or the customer controls the timing, validation, and architectural decisions surrounding the move.
Microsoft blocked creation of new non-AZ VpnGw1–VpnGw5 gateways on November 1, 2025. Existing gateways remain the issue, with VpnGw1 mapping to VpnGw1AZ and the same pattern continuing through VpnGw5 and VpnGw5AZ.
The date deserves attention because older versions of Microsoft’s gateway SKU mapping documentation named September 16, 2026. Current Microsoft Learn guidance describes migration continuing through September 2026, and Microsoft’s newer retirement reminder explicitly says September 30, 2026.
Administrators should record September 30 as the current deadline while continuing to monitor Azure Service Health, retirement notices, and the affected subscriptions. That does not make September 29 a sensible migration date. It gives teams slightly more room to validate gateways now, while Microsoft-controlled migration activity may already be approaching.
A gateway left on a non-AZ SKU after the rollout can also become operationally awkward before it visibly fails. Microsoft says remaining gateways can reject configuration and management changes until migration is completed. A tunnel that still passes traffic could therefore become an emergency problem when an administrator next needs to change BGP, connections, certificates, routing, or another gateway setting.
Use Azure Resource Graph Explorer to find affected gateways across the subscriptions available to the signed-in account:
That query establishes scope but not the attached public-IP SKU. The following query expands the gateway IP configurations and joins them to their public IP resources:
Export the results and assign an owner, business service, maintenance window, and migration decision to every row. An empty or unexpected public-IP result should trigger direct inspection rather than an assumption that the gateway is ready.
Gateways using Basic public IP resources need the supported Basic-to-Standard migration path. Microsoft says that process also moves the gateway to Generation 2. Gateways already using Standard public IP addresses are being upgraded to Gen2 through service updates before September 2026, without requiring a separate customer-run Gen2 migration.
This distinction matters because “change the SKU” can describe materially different operations. A Standard-IP VpnGw1-to-VpnGw1AZ move stays within the same tier and has no expected downtime. A Basic-IP gateway has an additional public-IP prerequisite, while a move that also changes capacity or crosses SKU families can incur the normal downtime associated with resizing.
Schedule the migration yourself when any of these conditions apply:
The key is to make that combination intentional. Microsoft’s automatic mapping will preserve the tier; it will not perform an architecture review on the customer’s behalf.
In a region without availability-zone support, the AZ SKU remains a regional deployment. Microsoft says zonal capability will be enabled when it becomes available in that region, but the SKU name alone does not prove that the current deployment spans zones.
Architecture documentation should therefore distinguish among three facts:
Teams that need to change region, topology, or redundancy strategy should treat this as a network architecture project rather than waiting for an in-place service migration. Automatic migration is designed to consolidate SKUs and preserve service, not redesign hybrid connectivity.
Review Terraform, Bicep, ARM templates, Azure Policy definitions, PowerShell, Azure CLI scripts, and internal deployment catalogs for references to the non-AZ SKU names. A successful portal change followed by an outdated deployment pipeline is not a completed migration.
The implementation plan should include these checks:
The safest default for enterprise gateways is now controlled migration, particularly with fewer than three months remaining before September 30. Automatic migration remains useful for uncomplicated Standard-IP deployments, but only after the organization has positively identified them as uncomplicated.
By September’s end, every affected gateway needs to be on an AZ-capable SKU, whether moved by its owner or by Microsoft. The teams that act now get to choose whether that event is a routine, tested network change or an externally timed service transition that happens to their production environment.
Microsoft’s current Azure VPN Gateway documentation places the consolidation through September 2026, while its latest retirement notices identify September 30, 2026 as the deadline. The previously circulated September 16 date appears in older regional documentation and should no longer be treated as the controlling date unless Microsoft changes its guidance again.
The practical question is therefore not whether the non-AZ SKUs are leaving. It is whether Microsoft or the customer controls the timing, validation, and architectural decisions surrounding the move.
September 30 Replaces the Earlier September 16 Target
Microsoft blocked creation of new non-AZ VpnGw1–VpnGw5 gateways on November 1, 2025. Existing gateways remain the issue, with VpnGw1 mapping to VpnGw1AZ and the same pattern continuing through VpnGw5 and VpnGw5AZ.The date deserves attention because older versions of Microsoft’s gateway SKU mapping documentation named September 16, 2026. Current Microsoft Learn guidance describes migration continuing through September 2026, and Microsoft’s newer retirement reminder explicitly says September 30, 2026.
Administrators should record September 30 as the current deadline while continuing to monitor Azure Service Health, retirement notices, and the affected subscriptions. That does not make September 29 a sensible migration date. It gives teams slightly more room to validate gateways now, while Microsoft-controlled migration activity may already be approaching.
A gateway left on a non-AZ SKU after the rollout can also become operationally awkward before it visibly fails. Microsoft says remaining gateways can reject configuration and management changes until migration is completed. A tunnel that still passes traffic could therefore become an emergency problem when an administrator next needs to change BGP, connections, certificates, routing, or another gateway setting.
Inventory the Public IP Before Choosing the Migration Path
The public-IP SKU is the first dividing line. A VpnGw1–VpnGw5 gateway using a Standard public IP is the cleanest candidate for either a controlled same-tier migration or Microsoft’s automatic process.Use Azure Resource Graph Explorer to find affected gateways across the subscriptions available to the signed-in account:
Code:
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,
gatewayGeneration = tostring(properties.gatewayGeneration),
activeActive = tostring(properties.activeActive),
vpnType = tostring(properties.vpnType),
gatewayId = id
| order by subscriptionId, resourceGroup, gatewayName
Code:
Resources
| where type =~ 'microsoft.network/virtualnetworkgateways'
| extend gatewaySku = tostring(properties.sku.name)
| where gatewaySku in~ ('VpnGw1', 'VpnGw2', 'VpnGw3', 'VpnGw4', 'VpnGw5')
| mv-expand ipConfig = properties.ipConfigurations
| extend publicIpId = tolower(tostring(ipConfig.properties.publicIPAddress.id))
| project subscriptionId,
resourceGroup,
gatewayName = name,
location,
gatewaySku,
gatewayGeneration = tostring(properties.gatewayGeneration),
activeActive = tostring(properties.activeActive),
publicIpId
| join kind=leftouter (
Resources
| where type =~ 'microsoft.network/publicipaddresses'
| extend publicIpId = tolower(id)
| project publicIpId,
publicIpName = name,
publicIpSku = tostring(sku.name),
publicIpAddress = tostring(properties.ipAddress),
publicIpAllocation = tostring(properties.publicIPAllocationMethod)
) on publicIpId
| project-away publicIpId1
| order by subscriptionId, resourceGroup, gatewayNameGateways using Basic public IP resources need the supported Basic-to-Standard migration path. Microsoft says that process also moves the gateway to Generation 2. Gateways already using Standard public IP addresses are being upgraded to Gen2 through service updates before September 2026, without requiring a separate customer-run Gen2 migration.
This distinction matters because “change the SKU” can describe materially different operations. A Standard-IP VpnGw1-to-VpnGw1AZ move stays within the same tier and has no expected downtime. A Basic-IP gateway has an additional public-IP prerequisite, while a move that also changes capacity or crosses SKU families can incur the normal downtime associated with resizing.
Controlled Migration Wins When Other Changes Are Already Planned
Waiting for Microsoft is defensible when the gateway uses a Standard public IP, the matching AZ tier provides the required capacity, the architecture is otherwise unchanged, and the organization can tolerate Microsoft choosing the migration timing. That is a preservation strategy, not an optimization strategy.Schedule the migration yourself when any of these conditions apply:
- The gateway supports production systems with formal maintenance, validation, or audit requirements.
- The public IP is Basic and must be moved to Standard through the supported migration workflow.
- The team intends to increase or reduce gateway capacity instead of making a same-tier move.
- Infrastructure-as-code definitions still declare VpnGw1–VpnGw5 and could later report drift or attempt to restore the retired SKU.
- Monitoring, automation, policy, or inventory tooling makes decisions based on the gateway SKU or generation.
- The migration is part of a broader redesign involving region selection, redundancy, routing, or tunnel topology.
The key is to make that combination intentional. Microsoft’s automatic mapping will preserve the tier; it will not perform an architecture review on the customer’s behalf.
An AZ Name Does Not Guarantee Zonal Resilience Everywhere
The AZ suffix can create a misleading sense that every migrated gateway immediately becomes zone redundant. Microsoft says AZ-capable SKUs are zone redundant only in Azure regions that support availability zones.In a region without availability-zone support, the AZ SKU remains a regional deployment. Microsoft says zonal capability will be enabled when it becomes available in that region, but the SKU name alone does not prove that the current deployment spans zones.
Architecture documentation should therefore distinguish among three facts:
- The gateway uses an AZ-capable SKU.
- The Azure region supports availability zones.
- The deployed gateway is operating with zone redundancy.
Teams that need to change region, topology, or redundancy strategy should treat this as a network architecture project rather than waiting for an in-place service migration. Automatic migration is designed to consolidate SKUs and preserve service, not redesign hybrid connectivity.
Change Control Must Cover More Than the Portal Toggle
Before approving a customer-controlled migration, capture the current gateway SKU, generation, public-IP resource, IP address, connection inventory, BGP state, tunnel status, active-active configuration, and relevant Azure Monitor baselines. Record on-premises peer configuration as well, even when the supported migration is expected to retain the public address.Review Terraform, Bicep, ARM templates, Azure Policy definitions, PowerShell, Azure CLI scripts, and internal deployment catalogs for references to the non-AZ SKU names. A successful portal change followed by an outdated deployment pipeline is not a completed migration.
The implementation plan should include these checks:
- Confirm that the gateway appears in the affected VpnGw1–VpnGw5 inventory and identify whether its public IP is Basic or Standard.
- Decide whether the target is the matching AZ tier or a separate capacity change requiring resize planning.
- Verify the region’s availability-zone support rather than inferring redundancy from the AZ suffix.
- Capture tunnel, routing, BGP, point-to-site, and monitoring baselines before the change.
- Update infrastructure-as-code, policies, cost models, dashboards, and operational documentation to recognize the AZ SKU.
- Run the migration during an approved window when the network requires controlled validation, even if Microsoft expects no downtime for a same-tier Standard-IP move.
- Validate every site-to-site and network-to-network tunnel, point-to-site access where applicable, learned and advertised routes, and application paths after the change.
- Define service-restoration actions in advance instead of assuming that reverting to the retired non-AZ SKU will be an available rollback method.
The safest default for enterprise gateways is now controlled migration, particularly with fewer than three months remaining before September 30. Automatic migration remains useful for uncomplicated Standard-IP deployments, but only after the organization has positively identified them as uncomplicated.
By September’s end, every affected gateway needs to be on an AZ-capable SKU, whether moved by its owner or by Microsoft. The teams that act now get to choose whether that event is a routine, tested network change or an externally timed service transition that happens to their production environment.
References
- Primary source: learn.microsoft.com
Gateway SKU Mappings - Azure VPN Gateway | Microsoft Learn
Learn about the changes for virtual network gateway SKUs for VPN Gateway.learn.microsoft.com - Primary source: WindowsForum
Azure AD Graph API Retirement: Essential Migration Guide for 2025 | Windows Forum
Microsoft’s looming retirement of the Azure AD Graph API is no longer a warning on the horizon—it’s now a fixed endpoint for IT departments, software...windowsforum.com