Blog ENG - MS Azure - Post 9 2025
If your Azure VPN Gateways still front-end on Basic SKU public IPs, migration to Standard SKU isn’t just housekeeping, it’s mandatory, and it will change how you plan, execute, and validate changes across on‑prem firewalls, BGP neighbors, and hybrid routes. Over the last year I’ve guided several teams through this transition. Below I’ll share the “why,” the “when,” and the “how,” plus the traps I see practitioners fall into and the checks that make the cutover boring (which is exactly what we want).
Why this migration matters
Microsoft retired Basic SKU public IP addresses on September 30, 2025. If you still have dependencies on Basic IPs, you should treat them as migration work with urgency to avoid outages. Beyond compliance, Standard public IPs give you a more modern and safer network posture: secure by default (closed inbound unless allowed by NSG), compatibility with services like Standard Load Balancer/Azure Firewall/NAT Gateway, and availability-zone options (zonal or zone‑redundant) you simply don’t get with Basic.
What’s changing behind the scenes (and what stays put)
– IP preservation with the Microsoft migration experience. If you use Microsoft’s guided migration for VPN Gateway, your gateway’s public IP does not change. That’s the single biggest operational win (no scrambling to update dozens of peer devices or firewall whitelists). Expect a brief downtime window (typically up to 5-10 minutes during the “Execute” step).
– Prepare-Execute-Commit flow. The guided experience runs in three phases: Prepare (often up to 40-60 minutes), Execute (the brief outage), and Commit (up to 30-60 minutes). Plan your window accordingly.
– GatewaySubnet sizing matters. The migration tool can fail if your GatewaySubnet is /28 or smaller. Ensure you have at least /27 (and three free IPs) before you begin.
– SKU shifts to AZ SKUs. Post‑migration, non‑AZ VPN gateway SKUs (VpnGw1-5) are moved to AZ variants (VpnGw1AZ-5), which is a net reliability win but something to watch for in IaC/monitoring baselines.
Field note: the Prepare phase is where most of the “waiting” happens. I schedule changes so that the Execute step lands in the center of the window, not at the tail, which gives me margin if validation reveals surprises.
Your migration paths, compared
There are three practical routes teams choose, each with trade‑offs. My recommendation is #1 whenever available.
1) Use Microsoft’s guided migration (recommended)
– What it is: A portal-driven experience to convert the gateway’s Basic public IP to Standard without changing the IP and to align the gateway SKU to AZ.
– Pros: Minimal downtime (typically up to 10 minutes), no IP churn, fewer touchpoints on on‑prem gear.
– Cons: Requires correct subnet sizing; rollout timing has varied by gateway mode (active‑passive first, active‑active later).
– Good fit: When IP retention is critical and your GatewaySubnet can be right-sized ahead of time.
2) Recreate the gateway in the same VNet (manual redeploy)
– What it is: Delete the existing gateway (on Basic IP), upgrade the disassociated public IP to Standard or create a new Standard IP, then deploy a new gateway and re‑establish all connections. IP will change if you create a new public IP or if your old one was dynamic.
– Pros: Immediate path when the tool isn’t available or subnet resizing is blocked by upstream constraints.
– Cons: Longer downtime (gateway build + connection rebuild), high touch across S2S/P2S/BGP, and operational risk if configs aren’t perfectly recopied.
– Good fit: Lab/smaller environments or when you’re also refactoring topology/route tables and can absorb an extended window.
3) Build a parallel (greenfield) hub and swing traffic
– What it is: Stand up a new VNet hub with a Standard IP gateway and gradually cut over routes and tunnels; retire the old gateway once validated.
– Pros: The cleanest rollback, near‑zero downtime if you sequence peers and UDRs carefully.
– Cons: Temporary double‑run costs; more moving parts (especially in hub‑and‑spoke with BGP).
– Good fit: Complex estates where change isolation and controlled swing are king.
Pre‑flight checks I never skip
– Inventory Basic public IP dependencies. Confirm every gateway and resource still on Basic and the impact radius (peer devices, NAT/firewall rules, monitored IPs/DNS).
– Right‑size GatewaySubnet. Ensure /27 or larger and ≥3 free IPs in the prefix; add prefixes if needed.
– Freeze change windows around the Execute step. Block noisy neighbors (patches, other network changes) during the 10‑minute outage.
– Understand Standard IP behavior. Plan NSGs because Standard IPs are closed by default; if you rely on inbound flows, explicitly allow them.
– Update runbooks and IaC baselines for AZ SKUs. Expect the gateway SKU to flip to VpnGwXAZ after migration.
The guided migration, step by step (from the trenches)
– Prepare: Start the migration in the portal; Azure validates prerequisites and builds what it needs behind the scenes. Plan up to 40-60 minutes here depending on size/region.
– Execute: This is the only step with expected downtime (often 5-10 minutes). Your tunnels drop, Azure swaps resources, then traffic resumes. I keep a short checklist ready: pings to key subnets, quick app smoke test, and a spot check of BGP session states.
– Commit: Once validation looks good, commit to finalize and clean up old resources (30-60 minutes typical). If something looks off, you can hold Commit and investigate.
Tip: If your estate mixes ExpressRoute and VPN, migrate the VPN side first (it’s what Microsoft recommends) so you don’t split brains on hybrid routing while you change SKUs.
What can bite you (and how to avoid it)
– Subnet too small or full. The tool errors out if GatewaySubnet cannot satisfy IP needs; expand to /27+ before the window.
– Assuming NSGs are optional. With Standard IP’s secure‑by‑default stance, inbound breaks until you explicitly allow flows (plan NSGs ahead of time).
– Unexpected IP change (manual path). If you delete/recreate the gateway or move to a brand‑new IP, don’t forget to update on‑prem peers, firewall rules, and any IP‑anchored monitoring.
– IaC drift. Pipelines that assert non‑AZ SKUs will “helpfully” revert your gateway unless you update desired state. Expect AZ after migration.
Quick decision table (how I choose)
– Need to keep the same public IP and minimize downtime? Use the guided migration.
– Tool not available / subnet constraints / small lab? Consider manual redeploy (accept IP change and longer downtime).
– Large/critical estate with strict rollback? Build a parallel hub and swing traffic in phases.
Post‑migration validation checklist (copy/paste into your change plan)
– Gateway reports Standard public IP and AZ SKU in the portal (VpnGwXAZ).
– S2S tunnels re‑established; IKE/IPsec SA counts and lifetimes look normal. (Spot check peer logs).
– BGP sessions Established; routes match pre‑cutover baseline.
– NSGs: confirm intended inbound/outbound rules reflect Standard IP’s closed‑by‑default stance.
– Application smoke tests: pick one path per spoke/subnet to catch asymmetric routing.
– Monitoring: verify alarms for tunnel drops cleared; new resource IDs reflected where relevant.
Final thoughts
Migrations like this are where good hygiene pays dividends. Right‑size your GatewaySubnet, lean on the guided migration to keep your IP, and make validation boring by scripting your checks. When the Execute step finishes and traffic snaps back cleanly, you’ll be glad you did the groundwork.