CloudRunbook | Practical Cloud Engineering
Azure VPN Gateway: portal migration for Basic Public IP on active-active gateways
Basic SKU public IPs have retired. Azure VPN Gateway offers portal-based migration to Standard Public IP on active-active gateways — who’s affected, and the runbook to get off Basic safely.
If you run Azure VPN Gateway (active-active) on a Basic Public IP, you are on a retired SKU. Use the portal migration to move to a Standard Public IP: plan a short maintenance window and validate address space and GatewaySubnet sizing before you touch anything.
Basic SKU public IP addresses reached retirement on 30 September 2025. If you are reading this with a Basic Public IP still attached to a production gateway, you are past the deadline, not ahead of it — treat the runbook below as urgent remediation and check your gateways today. Verify the current retirement guidance in Microsoft’s docs before you schedule the window.
What changed
Microsoft shipped a portal migration path for moving from Basic Public IP to Standard Public IP on active-active gateways, so the change can be done on your schedule rather than forced.
This sits inside the broader retirement of Basic Public IP and the legacy VPN gateway SKUs that depend on it.
Who is impacted
You should care if any of these are true:
- You have active-active Azure VPN Gateways
- They use a Basic Public IP address SKU
- You rely on the gateway for critical connectivity (on-prem, partners, branch sites)
- You have automation that assumes legacy IP resource shapes
If your gateway already uses a Standard Public IP, you’re likely not impacted.
Why it matters
- Operational risk: Customer-controlled migration can involve a short downtime window.
- You are past the deadline: Basic Public IP has retired. Anything still on it is running on borrowed time and has no supported path forward.
- Platform consistency: Standardising IP SKUs and gateway patterns makes landing-zone networking guardrails easier.
Find every Basic public IP still in the estate with Azure Resource Graph before you plan anything:
resources
| where type =~ 'microsoft.network/publicipaddresses'
| where tostring(sku.name) =~ 'Basic'
| project subscriptionId, resourceGroup, name,
attachedTo = tostring(properties.ipConfiguration.id)
| order by subscriptionId ascRunbook: prepare and execute the migration safely
- Inventory and scope
Identify gateways that match:
- Active-active VPN gateway
- Basic Public IP SKU
Capture for each:
- Subscription / RG / gateway name
- Region
- Gateway SKU
- BGP enabled? (yes/no)
- Connection types (S2S/P2S)
- Peak usage windows
- Pre-check: address space and GatewaySubnet sizing
Before running migration:
- Confirm you have sufficient IP space for the migration operation
- Validate GatewaySubnet meets current guidance for your gateway type
If you’re not sure, treat this as a change that can fail late if the subnet is constrained.
- Schedule a maintenance window
Assume a short interruption for a customer-controlled migration.
Practical guidance:
- Pick a low-traffic window
- Notify network consumers (site owners / app teams)
- Confirm rollback plan (see step 6)
- Change management (before you click anything)
- Snapshot current config (export ARM/Bicep/Terraform state)
- Capture screenshots / settings for:
- Gateway config
- Connections
- BGP settings
- Ensure you have break-glass access to the subscription
- Execute migration (portal-based)
Use the portal migration flow for:
- Basic Public IP -> Standard Public IP
- Active-active gateway
During execution:
- Monitor connection state
- Monitor tunnel down/up events
- Keep a live bridge open with impacted teams
- Rollback plan (decide this up front)
Define what “rollback” means in your environment:
- If connectivity does not restore within X minutes
- If BGP fails to converge within Y minutes
- If critical sites cannot reconnect
Document who can approve rollback and what your “stop” criteria are.
- Post-change validation
Validate:
- All S2S tunnels are connected
- BGP routes are learned as expected
- P2S users can connect (if used)
- Traffic flows for at least one real app path (not just tunnel state)
Then update your IaC/state so you don’t drift.
Success criteria
- ✓
Gateway Public IP is now Standard SKU (confirmed in portal + IaC).
- ✓
All VPN connections return to Connected state within agreed window.
- ✓
BGP (if enabled) reconverges and route tables show expected prefixes.
- ✓
At least one end-to-end application test passes across the VPN.
- ✓
Monitoring alerts return to baseline and no unexpected packet loss persists.
Comms template for stakeholders
Planned Azure change: we’re migrating the Public IP SKU for our Azure VPN Gateway (active-active) from Basic to Standard. The Basic SKU has retired, so this is required maintenance rather than an optional upgrade.
- Window: [date/time] — expect a short interruption.
- Impact: VPN connectivity may drop briefly during the change.
- Validation: we’ll confirm tunnels, BGP and app paths after the change, and update when complete.