Blog ENG - MS Azure - Post 8 2025
If you run hybrid networks at scale, you know that “gateway changes” are the kind of work that makes even seasoned architects pause. I’ve been there, on late‑night maintenance bridges with business‑critical workloads on the line, so I’m sharing the way I approach Azure ExpressRoute gateway migrations today: why the upgrade matters, how to plan, and the exact flow I use to move traffic with minimal fuss.
Why this upgrade matters (and why now)
Two things are driving most migrations I’m seeing:
– Resiliency: moving from older, single‑zone SKUs to availability‑zone-enabled gateways (ErGw1Az/ErGw2Az/ErGw3Az) lifts your SLA and reduces blast radius in zonal incidents.
– Public IP modernization: Basic public IPs for networking services are being retired on September 30, 2025, so ExpressRoute gateways should use Standard public IPs going forward.
Together, these changes improve reliability, performance, and long‑term supportability. Think of it as moving the “edge” of your hybrid architecture to today’s baseline rather than tomorrow’s technical debt.
What actually changes in the gateway
A migration upgrades your gateway SKU and swaps the gateway to a zone‑redundant deployment, while Azure provisions a new public IP behind the scenes and carries your configuration over. It’s a guided, side‑by‑side experience: the new gateway is created in the same GatewaySubnet, traffic is switched, and the old gateway is removed when you commit. Expect a brief interruption during cutover.
A practical note I’ve found useful: the migration validator checks whether your GatewaySubnet has enough addresses (I plan for /27 or larger). If it’s tight, Azure can add address space during migration so you don’t need to scramble mid‑maintenance.
Pre‑flight: the checklist I never skip
Before touching production, I treat this like any change with business impact:
– Change management (CRs, approvals, comms) and an agreed maintenance window that avoids peak activity.
– Backups of gateway, connection, and routing settings (plus a written rollback plan).
– Baseline tests: ICMP reachability, application checks, and latency/throughput samples you can compare after the cutover.
– Lower‑environment rehearsal (when possible) to de‑risk the flow.
– Stakeholder notifications (weeks out and a “final call” the day before).
Two field tips that save headaches:
– If you use Private Endpoints over ExpressRoute private peering, quiesce I/O on those paths during migration to avoid transient errors.
– If you have a VPN gateway co‑located in the same VNet, the migration tool is built to avoid affecting VPN traffic (but I still monitor it closely).
The 4‑stage guided migration (what it feels like in practice)
Azure’s guided experience in Portal/PowerShell is deliberately straightforward. Here’s the flow I run and the expectation I set with the team:
– Validate: Azure confirms the gateway can be migrated and that prerequisites are met (If not, fix blockers first).
– Prepare: Azure deploys the new zone‑redundant gateway and auto‑assigns the new Standard public IP. During this, the existing gateway is locked (no new/modified connections). This can take up to 45 minutes.
– Migrate Traffic: Select the new gateway and start traffic transfer; Azure moves data‑plane flows and connection config in up to 5 minutes with a brief interruption (up to 3 minutes) possible.
– Commit: When you’re satisfied, finalize by deleting the old gateway. Heads‑up: after commit, some connection names can’t be changed without recreation.
Under the hood, this is a controlled “blue/green” swap for the network edge, and it feels refreshingly predictable compared to traditional rebuilds.
Gotchas & pro tips from the field
– One gateway at a time: don’t try parallel migrations of multiple gateways, sequence them to keep risk contained.
– Naming & hygiene: Azure tags migrated gateways (for example “CreatedBy: GatewaySKUMigration”), helpful for inventory and audits. Avoid deleting the “new” gateway thinking it’s a temporary resource.
– GatewaySubnet discipline: keep NSGs/UDRs off the gateway subnet; the gateway needs clean management access and proper route propagation to function.
Planning ahead: FastPath and the new Scalable Gateway
If your hybrid estate is pushing high throughput or latency‑sensitive paths, put these two options on your roadmap:
– ExpressRoute FastPath lets on‑premises traffic bypass the gateway data plane and go directly to VMs/private endpoints (with specific SKUs and scenario limits). It’s a solid way to shave hops and lift throughput where supported.
– ErGwScale (Scalable Gateway) introduces fixed or auto‑scaling capacity up to 40 Gbps, with clean upgrade paths from Az‑enabled SKUs and the same Standard public IP requirement. It’s ideal when demand bursts or grows beyond Az SKUs.
Using the zone‑redundant migration now positions you to adopt either option later with far less refactoring.
Final thoughts
A gateway migration doesn’t have to be scary. With tight change discipline, a rehearsed flow, and Azure’s guided experience, the cutover becomes a controlled, measurable operation rather than a leap of faith.