Weekly Azure Change (Jan 2026): VPN Gateway portal migration for Basic IP on Active-Active • CloudRunbook

TL;DR

If you run Azure VPN Gateway (active-active) and it’s still using a Basic Public IP, Microsoft is rolling out portal-based migration (planned Jan 2026). Plan a short maintenance window and validate address space + gateway subnet sizing before you touch anything.

What changed

Microsoft’s VPN Gateway roadmap calls out a portal migration path for moving from Basic Public IP to Standard Public IP for active-active gateways (planned for Jan 2026).

This is part of the broader move away from Basic Public IP usage and legacy VPN gateway SKUs.

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.
Future-proofing: Basic Public IP is being deprecated; delaying migration increases risk later.
Platform consistency: Standardizing IP SKUs and gateway patterns makes landing-zone networking guardrails easier.

Runbook: 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

Message template

Planned Azure change: We’re migrating the Public IP SKU for our Azure VPN Gateway (active-active) from Basic to Standard as part of Microsoft’s roadmap.
Window: [date/time] (expected short interruption).
Impact: VPN connectivity may drop briefly during the change.
Validation: We’ll confirm tunnels/BGP/app paths post-change and update when complete.