The network is the migration’s critical path
During a phased migration, systems live in two places at once. A web tier in the cloud calls a database that has not moved yet. A reporting job on premises reads files that are now in object storage. Every one of those calls crosses the link between your site and the cloud. If the network design is wrong, the application does not fail cleanly, it just becomes slow and unreliable in ways that are hard to attribute.
For that reason, network design is its own deliverable within our cloud migration service. It builds on the landing zone and is informed by the dependency groups from the readiness assessment.
What good looks like
- Non-overlapping address space across every connected network, documented in one place.
- A hub that holds shared connectivity, egress control and DNS, with spokes for workloads.
- Private subnets for data and application tiers, public exposure limited to load balancers and gateways.
- Redundant connectivity to the site, tested for failure.
- Network definitions in code, with changes reviewed.
- Hybrid DNS that resolves names correctly from both sides.
Address planning first
Address planning is dull and decisive. Before building, we list every range in use: data centres, offices, VPN users, partner networks, other cloud accounts. We then allocate ranges for each cloud environment and region with room to grow, and we avoid ranges that commonly collide with home and office networks if remote users connect by VPN.
Subnet sizing deserves thought too. Container platforms, in particular, can consume large numbers of addresses, as the networking section of our EKS guide discusses. Leave space rather than packing subnets tightly.
Topology: hub and spoke
On AWS, a Transit Gateway acts as the hub, with VPC attachments for workload networks and a VPN or Direct Connect attachment for the site. Route tables on the gateway control which spokes can talk to each other. On Azure, the same pattern is a hub VNet with spoke peering, or Virtual WAN where there are many sites and regions.
An outline of the AWS side in Terraform:
resource "aws_ec2_transit_gateway" "hub" {
description = "migration-hub"
amazon_side_asn = 64512
default_route_table_association = "disable"
default_route_table_propagation = "disable"
}
resource "aws_customer_gateway" "onprem" {
bgp_asn = 65010
ip_address = var.onprem_vpn_public_ip
type = "ipsec.1"
}
resource "aws_vpn_connection" "site" {
customer_gateway_id = aws_customer_gateway.onprem.id
transit_gateway_id = aws_ec2_transit_gateway.hub.id
type = "ipsec.1"
static_routes_only = false
}
Disabling default association and propagation forces routes to be explicit, which is safer when production and non-production networks share a gateway. Dynamic routing with BGP is preferred over static routes, since it fails over without manual changes.
Choosing the link
| Option | Strengths | Limits |
|---|---|---|
| Site to site VPN | Quick to set up, low cost, encrypted | Internet-dependent latency, throughput caps per tunnel |
| Direct Connect or ExpressRoute | Consistent latency, high bandwidth, private path | Lead time, recurring circuit cost, needs a provider or colocation |
| Both | VPN as backup for the circuit | More to operate and test |
For bulk storage and data transfer, a dedicated circuit can save weeks, but for modest volumes a VPN is enough and the circuit is not worth ordering. We make this call from the measured data volumes, not by default.
Name resolution and egress
Two pieces of networking are easy to forget. First, DNS: migrated systems must resolve on-premises names and on-premises systems must resolve cloud names. On AWS that is Route 53 Resolver endpoints with forwarding rules, on Azure it is Private DNS zones and a resolver. Second, egress: partners often allow-list your public IP addresses. If cloud traffic leaves from new addresses, those lists must change before cutover. We use NAT gateways or a firewall with fixed addresses and plan the partner notifications, which links directly into the DNS cutover plan.
Decisions and trade-offs
Transit Gateway or VPC peering. Peering is simple and cheap for a few networks but does not scale, since it is not transitive. A gateway adds cost and clarity once you pass a handful of VPCs.
Central firewall or security groups only. Security groups and network security groups cover most needs. A central firewall adds inspection and egress filtering, at the cost of throughput limits and complexity. Regulated environments usually justify it. Small ones often do not.
When not to do it. If a workload is chatty with an on-premises system that is staying, moving it alone can make things worse. We either move the pair together or retain both.
A worked example: testing before a wave moves
Before a wave of servers moves, we pick the three or four network flows that wave depends on, for instance the application server reaching a licence server on premises, and the reporting job reaching a file share. We run each flow from a test instance in the spoke network, check that the firewall allows it, confirm the name resolves from both sides, and measure round-trip time with a tool such as iperf3 or plain ping. Any flow that fails or is noticeably slow is fixed or the dependent systems are regrouped into the same wave. This small routine catches most surprises while they are still cheap to fix.
Common failure modes
- Overlapping ranges discovered after the VPN is built.
- Asymmetric routing through a firewall, where return traffic takes a different path and is dropped.
- Single tunnel dependence. The link becomes a single point of failure for the migration.
- MTU and fragmentation issues that break large transfers but not small tests.
- Firewall rules opened too widely during troubleshooting and never tightened. The security baseline reviews them.
Delivery and handover
The network code is in your repository. We hand over a diagram, the address plan, a routing table explanation, and a test record showing failover and measured throughput. Operational procedures go into the operations runbook.
How to tell it is working
Latency between sites is measured and acceptable for the workloads that span them. A tunnel failure causes failover with no manual action. New environments pick address ranges from the plan without conflict. No team asks for a rule to be opened “temporarily” more than once. To discuss your connectivity options, contact us.