The data gravity problem
Applications can be rebuilt in days; moving tens or hundreds of terabytes takes longer. The network between your data center and the cloud often decides the migration timeline.
Step 1: Inventory the data
List every dataset to move, with its size and daily change rate. Include databases, file shares, object stores and VM images.
Step 2: Calculate transfer time
Divide total volume by realistic throughput — typically 70–80% of link capacity after protocol overhead. A large dataset over an undersized link can take weeks.
Step 3: Seed, then synchronise
Copy the bulk of the data first while systems keep running. Then use replication to keep the cloud copy in sync with ongoing changes.
Step 4: Plan the final cutover
At cutover, you stop writes, perform a final sync and switch users over. The time this takes depends on the change rate and the bandwidth available. Make sure it fits within your agreed downtime.
Step 5: Right-size afterwards
Once the migration is complete, steady-state traffic is usually much lower. With flexible private connectivity, you can reduce bandwidth instead of paying for migration-sized capacity forever.
A private path helps
A dedicated DC-to-Cloud connection gives predictable throughput, so your timeline estimates hold. Talk to us about migration capacity.
