Unable to Migrate the VPN Public IP from basic to Standard due to Subnet Limiataion

Abrar Adil S 476 Reputation points
2026-06-17T18:32:12.5766667+00:00

We are currently facing a challenge while migrating an Azure VPN Gateway that uses a Basic Public IP, as Basic Public IPs are being retired.

The existing VPN Gateway is deployed in a spoke VNet and uses a GatewaySubnet that is only /29 in size. Due to the subnet size limitation, we are unable to perform an in-place migration to a Standard Public IP and would need to delete the existing VPN Gateway, resize/recreate the GatewaySubnet, and then deploy a new VPN Gateway. Based on our estimates, the deletion and recreation process could take approximately 2.5 to 4 hours.

To avoid this downtime, we explored utilizing an existing VPN Gateway deployed in a Hub/Landing Zone VNet that already has an active Site-to-Site connection to the on-premises environment. The idea was to establish VNet peering between the spoke VNet and the hub VNet and use Gateway Transit.

However, Azure does not allow a VNet to use a remote gateway while it already has its own VPN Gateway configured. This means we would first need to delete the existing VPN Gateway in the spoke VNet, then establish peering and configure Gateway Transit. Even this approach introduces approximately 30–45 minutes of downtime during VPN Gateway deletion and peering reconfiguration.

Additional considerations:

  • Site-to-Site VPNs are configured using static routing.
  • BGP is not configured on either VPN Gateway.
  • The business is not comfortable with 30–45 minutes of downtime, and certainly not several hours.

Has anyone encountered a similar scenario? Is there any supported approach to achieve a seamless or near-zero downtime migration from a spoke VPN Gateway to a hub/shared VPN Gateway when using static routing and no BGP? Are there any alternative Azure networking designs or migration strategies that could avoid the dependency on deleting the existing VPN Gateway before enabling Gateway Transit?
Does Microsoft from the backend have an option to upgrade the SKU of the Public IP?

Azure VPN Gateway
Azure VPN Gateway

An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.

1 answer

Sort by: Oldest
Most helpful Newest Oldest
  1. Sina Salam 31,456 Reputation points Volunteer Moderator
    2026-06-20T16:53:39.4366667+00:00

    Hello Abrar Adil S,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that you are unable to Migrate the VPN Public IP from basic to Standard due to Subnet Limitation.

    The failure is caused by the GatewaySubnet size/IP availability requirement for the Azure VPN Gateway Basic Public IP migration workflow. For VPN Gateway SKUs such as VpnGw1-5 and legacy Standard/HighPerformance, Microsoft requires sufficient free IP capacity in GatewaySubnet; so, if the subnet is /28 or smaller, the migration tool may fail. The supported remediation is to add additional address prefix space to GatewaySubnet so it reaches /27 or larger effective capacity, then run the official VPN Gateway Basic Public IP to Standard Public IP migration workflow. - https://learn.microsoft.com/en-us/azure/vpn-gateway/basic-public-ip-migrate-about, and https://learn.microsoft.com/en-us/azure/vpn-gateway/basic-public-ip-migrate-howto.

    The best practice for resolution is to:

    • Do not delete the existing VPN Gateway first if the spoke VNet has available non-overlapping address space.
    • Add another valid prefix to the existing GatewaySubnet to satisfy the VPN Gateway migration prerequisite.
    • Run the official Azure VPN Gateway “Migrate to Standard IP” workflow from the Virtual Network Gateway configuration blade.
    • Validate that the Public IP SKU becomes Standard and that the VPN tunnel remains functional.
    • Use hub gateway transit only as a separate redesign option, not as the primary migration path, because a spoke VNet cannot use a remote hub gateway while it still has its own VPN Gateway.

    This is the reliable supported path that can preserve the existing VPN Gateway public IP address and avoid the longer delete/recreate outage., although the VPN Gateway SKU may be migrated from a non-AZ SKU to an AZ SKU, for example VpnGw2 to VpnGw2AZ. - https://learn.microsoft.com/en-us/azure/vpn-gateway/basic-public-ip-migrate-howto, and https://learn.microsoft.com/en-us/azure/vpn-gateway/basic-public-ip-migrate-about Therefore, if the spoke VNet has no available address space to expand GatewaySubnet, then near-zero downtime is not realistically achievable with your current design. In that case, the supported alternatives are either a planned VPN Gateway redeployment or a planned hub gateway transit cutover after deleting the existing spoke VPN Gateway. - https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-delete-vnet-gateway-portal, and https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit

    Use the below official resource links for more reading and implementation steps:

    I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

    Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.