Migrating Massive VMs: Overcoming Cloud Ingestion Bottlenecks

veeam - cloud migration - aws - azure - oci - rto - ingestion

🧮 The math nobody runs until it is too late

Before any tooling conversation, run the transfer math. This is where most migrations go sideways. The team focuses on which cloud, which landing zone, which migration service, and completely forgets to ask: how long does it actually take to move this data over the wire we have?

Those numbers are from AWS and Oracle's own documentation. The 100-day figure for 100TB over 100Mbps is not a theoretical edge case. It is a real scenario that gets hit by organizations on commodity internet connections who assumed the migration would "just happen" over a few weekends. The 8-month figure for 1PB over 500Mbps comes directly from AWS Snowball documentation explaining why physical seeding exists at all.

The first thing you do before any cloud migration project involving serious data volume is calculate your migration window against your available bandwidth. If that math does not work, no tool, no proxy optimization, and no clever scheduling fixes it. You need more pipe or a different seeding strategy before the project starts.

⚠️ Where the actual bottleneck lives

Cloud migration bottlenecks tend to show up in one of four places, and diagnosing the wrong one wastes significant time. Veeam's own bottleneck detection framework identifies source, proxy, network, and target as the four candidates. For cloud migrations, network and target are almost always the primary constraints. But the failure modes within each are different.

The network bottleneck is the one people think about: not enough bandwidth. But there is a second, less obvious network constraint: latency-induced throughput collapse. TCP window sizes and protocol overhead mean that high-latency links cannot saturate even moderate bandwidth. A 10Gbps Direct Connect with 20ms RTT delivers less usable throughput for sequential large transfers than the bandwidth number suggests. Protocol-level optimizations matter here, specifically enabling jumbo frames on Direct Connect and ExpressRoute connections, which reduces packet overhead and improves throughput for large sequential writes.

The target bottleneck on cloud migrations is usually the cloud provider's ingestion pipeline, not your network. AWS EC2 import, Azure Migrate's replication appliance, and OCI's import service all have processing constraints that cap how fast they can consume incoming data, regardless of how fast you can push it. You can saturate your own upload pipe and still be queued on the provider side. Understanding the per-provider ingestion architecture changes how you design the migration.

🔧 How Veeam's cloud migration path works

Veeam's primary migration mechanism to public cloud is the Direct Restore path: take an existing on-premises VM backup and restore it directly to EC2, Azure VM, or (for OCI, using agent-based workflows) to OCI compute. The backup is the migration artifact. You are not running a separate migration tool alongside your backup stack. This matters operationally: your migration run is also your last backup. If the migration fails mid-transfer, you still have the backup. The restored VM in the cloud is your production system from the moment you fail over DNS.

For AWS and Azure, Veeam deploys a cloud-side proxy appliance as part of the restore process. This proxy appliance runs inside your target cloud account and handles the local disk-side operations: receiving the backup stream, converting it to the native cloud disk format (EBS for AWS, managed disks for Azure), and attaching it to the new instance. The proxy appliance is the key to understanding why the Veeam cloud restore path outperforms raw VM import workflows. The conversion and disk attachment happen in-cloud, not on the wire, and the backup data travels in Veeam's compressed, deduplicated format until it lands at the proxy.

For OCI, there is no native Veeam OCI plugin in the current release. The path for OCI migrations uses Veeam Agents in managed mode, with OCI Object Storage now supporting the S3-compatible API that Veeam's object storage repositories target. Oracle Cloud VMware Solution (OCVS) gets full Veeam support because it is a VMware SDDC inside OCI: VBR can reach it natively and the standard vSphere backup and restore paths apply.

☁️ AWS: Direct Connect, DataSync, and the seeding problem

🔵 Azure: ExpressRoute, the process server, and scale-out

🔴 OCI: FastConnect, DRG routing, and the OCVS path

🌱 The seeding strategy: doing the initial transfer right

For migrations above a few terabytes, the standard migration pattern is two-phase: seed the initial bulk copy, then switch to delta replication for the final cutover. Getting the seeding phase right is what keeps the cutover window short.

The seeding phase is the initial full copy of the VM disk to the cloud. Everything that happens after that is incremental. If the seed is clean and complete, the delta replication that runs up to cutover is small: only changed blocks since the last sync. If the seed is slow, interrupted, or partial, the delta grows and the cutover window stretches. A 10TB VM that changes at 5% per day generates 500GB of delta per day. If your seed took two weeks because of bandwidth constraints, you have potentially 7TB of delta to replay before you can cut over. This is the math that creates extended migration windows for large workloads.

The correct approach for large seedings is to isolate the seed job from production backup windows. Give it dedicated bandwidth and run it during a sustained window where you can monitor throughput consistently. For Veeam specifically, the initial EC2 restore or Azure restore job is effectively your seed. It runs once, gets the VM to the cloud, and from there incremental backup copy jobs keep the cloud copy in sync until cutover. The cloud-side copy is your DR target during the transition period and your production system after cutover.

Backup copy job as pre-staging

A useful pattern for very large VMs: use a Veeam Backup Copy Job to an object storage repository (S3, Azure Blob, or OCI Object Storage) as the pre-staging step before the final restore. This separates the bulk data movement from the actual restore conversion. The backup copy runs continuously in the background, keeping the cloud-side copy of the backup up to date. When you are ready to cut over, the restore job runs from data that is already in the cloud, not from data that needs to traverse the WAN in real time. The cutover transfer is only the delta since the last backup copy sync, which can be minutes of change rather than days.

📶 Cloud gateway and proxy optimization

The cloud-side proxy or gateway appliance is the single most impactful optimization point in a Veeam cloud migration. It is also the most commonly undersized component. Several tuning decisions directly affect throughput.

For AWS, the proxy appliance should be an instance type with EBS-optimized I/O and sufficient network bandwidth for the expected ingest rate. Instance types like m5.xlarge or c5.large give you enough CPU for decompression and enough network to keep up with a 10Gbps Direct Connect circuit. For Azure, the proxy appliance should be in the same region as the restore target. Use a VM size with premium SSD support for the proxy's temporary disk: standard HDD-backed proxy appliances create a local storage bottleneck during disk staging.

Jumbo frames deserve attention on both Direct Connect and ExpressRoute. Both services support jumbo frames (9001 bytes MTU for Direct Connect, 9000 bytes for ExpressRoute). Enabling jumbo frames reduces the TCP/IP overhead per byte transferred and meaningfully improves throughput on large sequential transfers. This requires configuration on both your on-premises routing equipment and the virtual network gateway in the cloud. It is not enabled by default on most configurations and is consistently overlooked.

Veeam's WAN acceleration is applicable in scenarios where you have a WAN accelerator deployed on the cloud side. For direct internet migrations or VPN-based migrations where bandwidth is the hard constraint, WAN acceleration reduces the effective data volume by deduplicating the stream at the source before it traverses the link. For migrations where the cloud proxy handles the final data, WAN acceleration between VBR and the proxy is less impactful because the Veeam backup format is already compressed and deduplicated. The bigger win is right-sizing the proxy and getting off public internet onto a dedicated circuit.

⏱️ Keeping RTO defensible during cutover

The cutover moment is where migrations either go smoothly or produce a war room. Three things determine whether your RTO holds up: how current is the cloud-side data at the time of cutover, how fast can the restored VM reach a functional state, and what is your rollback plan if the cloud VM does not come up cleanly.

Data currency is controlled by how recently your last backup copy sync ran. If you are using the backup copy pre-staging pattern described above, the delta at cutover can be very small. Schedule one final incremental sync to the cloud immediately before starting the cutover procedure. This minimizes the amount of new data to process during the final restore.

Veeam's Instant Recovery to cloud allows you to start the cloud VM directly from backup storage before the restore is complete. For AWS and Azure this means the VM is running while the remaining disk data is being hydrated in the background. RTOs measured in minutes rather than hours are achievable for workloads where you need the service available while the full restore finishes. For production cutover, verify the VM is healthy and the full restore is complete before decommissioning the on-premises instance.

Rollback planning is the piece teams skip because they are optimistic about the migration succeeding. The on-premises VM should remain intact and powered off until the cloud instance is verified stable under production load. Do not decommission or deallocate the source VM at the moment of cutover. Keep it for at least 48-72 hours post-cutover. For very large VMs where storage costs are a concern, snapshot the source VM rather than leaving it running. The point is to preserve the rollback option until you are confident the cloud instance is solid.

📋 Provider comparison: migration connectivity at a glance