Single service comparison

Azure ExpressRoute is a single service that spans port provisioning, BGP peering (private/Microsoft/public), and gateway integration, exposing virtual network gateways (ExpressRoute gateway) and Global Reach for inter-circuit routing. Huawei Direct Connect (DC) separates these concerns: a Direct Connect is the physical port/hosted connection, a Virtual Gateway (VGW) terminates BGP in a VPC, and a Virtual Interface (VIF) carries the BGP peering with route policies. Architecturally expect Huawei to compose multiple sub-resources where Azure presets them inside one circuit resource, so automation and Terraform models differ.

Redundancy and peering differ. ExpressRoute offers redundant circuits per peering location and Global Reach to link circuits across regions; Microsoft peering reaches Microsoft 365/PaaS over private paths. Huawei DC supports active/active or active/standby redundant connections and uses Enterprise Router (ER) for cross-VPC and cross-region transit, but there is no direct equivalent to Microsoft peering for Microsoft SaaS, and traffic to Huawei PaaS still flows through VPC endpoints or public addresses. Validate BGP timers, AS-path handling, advertised route limits, and route table quotas per region rather than assuming parity.

Operations and pricing boundaries differ. Azure bills circuit port hours plus a gateway SKU and, with Local/Standard/Premium add-ons, regional egress scope. Huawei DC bills the port/VIF and VGW resource-hours, with bandwidth charged on the port or shared dedicated bandwidth, while VPC Endpoint, ER, and NAT may add charges. SLAs, maintenance windows, and the responsibility split (partner-managed last-mile vs. Huawei-managed cloud port) should be re-read per region, because port availability and partner ecosystem are not globally uniform.

Inventory the ExpressRoute topology first: circuit SKU (Local/Standard/Premium), peering types, BGP autonomous systems, advertised prefixes, route filters, gateway SKU, Global Reach links, and any ExpressRoute Direct channels. Map each to Huawei constructs: port or hosted Direct Connect, Virtual Gateway (VGW), Virtual Interface (VIF), and Enterprise Router (ER) where cross-VPC/cross-region transit is needed. Do not assume one-to-one feature parity for Microsoft peering or Global Reach; flag workloads that depend on private Microsoft 365 or cross-circuit routing for redesign.

Provision the Huawei side before cutover. Order an equivalent Direct Connect port or hosted connection through a Huawei partner, create a VGW attached to the target VPC (or to an ER for hub-and-spoke), and build the VIF with matching BGP AS numbers, prefixes, and route policies. Recreate route propagation, custom route tables, and BFD/fast-failover settings, and confirm prefix limits per VIF and per region. Recalculate bandwidth sizing on Huawei's port speeds and shared bandwidth plans rather than Azure's circuit inbound/outbound model.

Migrate traffic in a staged cut. Run the Huawei path alongside ExpressRoute during a parallel-validation window using overlapping prefixes and AS-path prepends or local preference to control egress, then shift weight and validate latency, packet loss, and BGP convergence before decommissioning the Azure circuit. Confirm that managed services, DNS, and Microsoft SaaS access that previously used Microsoft/public peering still reach their endpoints acceptably over the Huawei path, since that private SaaS reach is not natively replicated.

Recompute TCO and governance for the new model. Expect line-item changes: Huawei VGW/VIF/ER resource-hours, port bandwidth, and potential VPC Endpoint or NAT traffic charges replacing Azure gateway-hours and circuit add-ons. Update monitoring (Cloud Eye on DC/VGW/VIF), alerting on BGP session and port state, IAM scoping, and tagging. Document residual gaps such as Microsoft-peering private SaaS reach and any cross-circuit Global Reach behaviors that now require ER-based alternatives.