Home / Azure

AzureHow-toAdvanced

Transformation: from self-managed hub-spoke to Azure Virtual WAN

When and how to move a customer-managed hub-spoke network to Azure Virtual WAN. Compare the models, design hubs and routing intent, migrate spokes and branches in phases, and avoid the routing surprises that cause outages.

Deepak Bhardwaj3 min read

Applies toAzure Virtual WAN Standard, secured virtual hubs with Azure Firewall, ExpressRoute and VPN gateways

Should you move?

Signal Points to
Many regions, many branches (SD-WAN, VPN), any-to-any routing needed Virtual WAN
One or two regions, few connections, heavy custom routing (NVAs, UDR tricks) Keep hub-spoke
Team spends too much time on UDRs and gateway transit Virtual WAN
Need features not supported in vWAN hubs Keep hub-spoke for now

Virtual WAN makes Microsoft manage the hub router, gateways and transit. You give up some control in exchange for much less routing work.

1. Design

  • One virtual hub per region with a non-overlapping /23 or larger hub prefix.
  • Routing intent with Azure Firewall (secured hub) to inspect private and/or internet traffic, instead of hand-built route tables.
  • Gateways inside the hub: ExpressRoute, site-to-site VPN, point-to-site.
  • DNS: keep a DNS Private Resolver in a shared-services spoke; vWAN hubs don't host custom DNS.

2. Build the vWAN side in parallel

az network vwan create -g rg-vwan -n vwan-prod --type Standard
az network vhub create -g rg-vwan -n vhub-weu --vwan vwan-prod --address-prefix 10.100.0.0/23 -l westeurope

Deploy the firewall in the hub and enable routing intent from Firewall Manager or IaC.

3. Migrate in phases

  1. Connect old hub to new hub temporarily (connect the old hub VNet as a spoke of the vHub, or use a VNet connection plus static routes) so both worlds can talk.
  2. Move spokes one by one: remove the peering to the old hub, add a vHub connection, remove UDRs that pointed at the old firewall.
  3. Move on-premises connectivity: connect the ExpressRoute circuit to the vHub ER gateway, then remove it from the old gateway. Do branches in a maintenance window.
  4. Decommission the old hub gateway, firewall and route tables.
az network vhub connection create -g rg-vwan --vhub-name vhub-weu -n conn-spoke-app \
  --remote-vnet /subscriptions/<sub>/resourceGroups/rg-app/providers/Microsoft.Network/virtualNetworks/vnet-app

Warning

A spoke can't be peered to the old hub (with gateway transit) and connected to the vHub at the same time. Plan a short window per spoke and test reachability both ways right after.

4. Validate routing

az network vhub get-effective-routes -g rg-vwan -n vhub-weu \
  --resource-type HubVirtualNetworkConnection \
  --resource-id <connection-id> -o table

Check: spoke-to-spoke traffic goes through the firewall (if intended), on-premises prefixes are learned, and internet egress follows routing intent.

5. Operate

  • Monitor hub router and gateway metrics; enable firewall diagnostics.
  • Use Network Watcher Connection Monitor tests between key spokes and on-premises.

Checklist

  • Hub prefixes and routing intent design approved
  • Old-to-new interconnect tested before moving any spoke
  • UDRs removed from migrated spokes
  • ExpressRoute and VPN moves done in maintenance windows with rollback
  • Old hub resources removed and costs dropped

Related fixes