What could go wrong when a company decides to move its entire digital life from one building to another? Ask anyone who has done it, and you will hear stories about a move that was supposed to take six months and took two years, about a network link nobody sized correctly, or about a compliance officer who stopped the whole project two weeks before cutover. Data center migration is not a single event. It is a long, phased engineering project with a business attached to it, and the challenges are rarely the ones teams plan for.
This article walks through the hard parts: bandwidth physics, application dependencies, latency, data residency law, cost surprises, decommissioning, and the human side of keeping services alive while the floor moves underneath them.
The move is a marathon, not a cutover
The most common mental model failure is treating migration as a switchover weekend. In practice, large migrations run in waves over months or years. Google’s own account of its “Datacenter Mover” project, which shifted data between data centers in phases over roughly two years with continuous availability as the binding constraint, is a useful reality check for anyone budgeting a quarter.
Why so slow? Because every workload has neighbors. A database has an application server, which has a caching layer, which has a batch job, which has a reporting extract that feeds a finance team’s spreadsheet. You cannot move the database without moving or re-pointing everything that touches it, and you cannot move the application server until its dependencies are reachable from the new location.
Practical tip: build the migration wave plan from dependency data, not from an org chart. Teams that group workloads by business unit rather than by network and data dependency almost always discover a surprise cross-connection mid-wave.
Bandwidth and transfer time are physics, not opinions
The arithmetic is unforgiving. At a perfect 100 Gbps line rate, moving one petabyte takes about 22 hours. Real-world throughput is lower, WAN links are shared with production traffic, and TCP behavior over long distances rarely delivers line rate. Suddenly, a dataset that “looks small” on a storage dashboard becomes a multi-week transfer.
This is exactly why physical shipping appliances exist. When a network transfer would take weeks or months, putting disks in a truck can genuinely be faster. The engineering challenge is not choosing the method; it is knowing your actual data volumes, including the snapshots, backups, and forgotten archives nobody has inventoried.
Common mistakes here:
- Sizing transfers from the “active” dataset and ignoring cold data that still has to move.
- Forgetting that compression ratios vary wildly by data type, so a 3:1 assumption from one dataset does not generalize.
- Failing to throttle transfers, then degrading production latency for weeks.
A disciplined team inventories data before it books any transit capacity. If you want a structured starting point, this walkthrough of what to inventory before a cloud migration covers the categories that most often get missed.
Application dependencies and the hidden coupling problem
Legacy estates are full of invisible coupling. Hard-coded IP addresses, undocumented cron jobs, service accounts with firewall exceptions granted in 2016, and a license server that three unrelated teams quietly depend on. Every one of these is a landmine that detonates during cutover.
The fix is early, honest discovery. That means network flow analysis rather than application owner interviews alone. Owners routinely underestimate what their systems talk to, because they only know the documented path.
A dependency mapping sequence that works
- Capture flow data for at least 30 days across every segment that will move.
- Tag each flow with an owner, a criticality tier, and a migration wave.
- Identify flows that cross wave boundaries; these are your risk register.
- Test re-pointing the riskiest cross-wave flows in a lab before any production move.
- Re-run discovery after each wave, because migrations change traffic patterns.
The last step matters more than people expect. Moving one workload often creates new east-west traffic that did not exist before, and capacity plans built on the old baseline will be wrong.
Latency and placement: the constraint you cannot compress
Moving a workload changes its round-trip time to users and to every service it calls. A database that sat two racks from its application now sits 40 milliseconds away, and a chatty application making 200 sequential calls per page load just got noticeably slower.
This is standard networking behavior, not a mystery, but it is routinely underestimated. Teams should measure real round-trip latency between candidate locations and the workload’s heaviest callers before committing, and should consider whether the application can be made less chatty. Sometimes the answer is architectural: batch the calls, add a cache, or accept a regional deployment instead of a single consolidated one.
Latency also interacts with resilience. Stretching a cluster across longer distances makes synchronous replication fragile, and failover behavior changes. Capacity discussions and interconnect choices deserve their own analysis; this piece on where interconnects enter the capacity discussion explains why link design shapes what is actually achievable.
Compliance, data residency, and the rules that stop projects
Legal constraints can halt a migration that is technically perfect. Under the EU’s General Data Protection Regulation, transfers of personal data outside the European Economic Area are restricted and require a valid legal mechanism. The 2020 Schrems II judgment by the Court of Justice of the European Union invalidated the Privacy Shield framework and forced many organizations to re-examine their transfer arrangements. (NIST Cybersecurity Framework overview)
The practical implication: before designing the target architecture, confirm which datasets contain personal data, where the data subjects are, and which jurisdictions the target facility sits in. A migration that consolidates European customer records into a single non-EEA region may be cheaper and faster, and also unlawful.
Two habits that prevent pain:
- Map data classification to physical location, not to logical system. The same application may hold regulated and unregulated data in different tables.
- Involve legal and privacy teams at design time, not at sign-off. Retrofitting a lawful transfer mechanism after the architecture is built is expensive.
Multi-tenant platforms add another layer, because tenant boundaries and data separation must survive the move intact. The approach described in this guide to separating tenant data in an enterprise assistant is a useful model for thinking about isolation during and after migration. (Data migration)
Cost surprises: egress, double-running, and the bill nobody modeled
The most predictable surprise in any migration is paying for two environments at once. During cutover windows, source and target both run, both consume power and licenses, and both need staff. That overlap period is where budgets quietly break.
Egress fees are the second classic. Moving large volumes of data out of a cloud provider or between regions can cost far more than the storage itself. Regulators have taken notice: the EU Data Act, Regulation (EU) 2023/2854, includes provisions intended to make switching between cloud providers easier and to address the charges that lock customers in. Reading the actual text is worthwhile for anyone negotiating an exit.
A clearer way to track cloud data transfer costs offers a practical framing for separating transfer charges from compute and storage, which is the only way to see the true cost of a move before it happens.
Testing, rollback, and the recovery drill you hope to never need
A migration plan without a tested rollback is a wish. The uncomfortable truth is that most rollback plans are written, not rehearsed, and the first rehearsal happens during an incident.
What actually works is a recovery drill run against realistic conditions: restore a real dataset from the target environment, measure how long it takes, and confirm the application can start against it. Managed database services add their own quirks, including snapshot retention windows and restore-time behavior that differs from self-hosted engines. A structured approach to building a recovery drill for a managed database covers the mechanics.
Set an explicit decision point before cutover: if the target environment fails validation by hour X, the team rolls back, no debate. Teams that pre-agree the threshold avoid the worst outcome, which is a half-migrated estate with unclear ownership.
Decommissioning: the step everyone forgets
The migration is not finished when the new racks are live. It is finished when the old ones are securely erased and released. Media sanitization is a defined discipline; NIST Special Publication 800-88 Revision 1 sets out guidelines for media sanitization that many organizations adopt as their reference standard for wiping drives before reuse or disposal.
Skipping this step creates two problems. First, a security exposure: drives leaving a facility with readable data. Second, a cost exposure: organizations keep paying for empty cages and idle circuits because nobody owns the decommission checklist.
A workable decommission gate includes: confirmed data destruction records, revoked network interconnects and cross-connects, cancelled support contracts tied to serial numbers, updated asset inventory, and a final power-down verification.
The human factors that decide the outcome
Technical challenges get the planning documents. People challenges decide whether the plan survives contact with reality.
The recurring patterns are familiar. The application owner who refuses to sign off until a feature ships. The on-call engineer who is expected to run cutover at 2 a.m. after a full week of incident work. The business stakeholder who was never told the reporting dashboard would be unavailable for a weekend.
What helps, in practice:
- Name a single migration owner who has authority to sequence waves and does more than coordinate meetings.
- Publish a freeze calendar and honor it, so teams can plan around cutover windows.
- Run game days with the actual on-call rotation rather than a volunteer strike team.
- Communicate in business terms: which services are affected, for how long, and what users should do.
None of this is glamorous. All of it correlates with migrations that finish.
Conclusion
Data center migration challenges cluster into a few honest categories: the physics of moving bytes, the tangle of application dependencies, the hard edges of latency and law, the bill that arrives twice, and the people asked to hold it all together. None of these is solved by a better slide deck. They are solved by discovering early, sizing honestly, testing rollback before you need it, involving legal and finance at design time, and finishing the job with a real decommission.
The teams that succeed treat migration as a program with waves, gates, and rehearsals rather than a project with a finish line. That framing alone prevents most of the failures described above.
What is the biggest challenge in data center migration?
Most practitioners point to hidden application dependencies rather than hardware or bandwidth. Undocumented connections between systems surface only during cutover, when changing them is most expensive. Bandwidth and compliance rank close behind, but dependency discovery is the challenge that most often forces schedule slips.
How long does a large data center migration usually take?
Large migrations typically run in phases over many months, and multi-year timelines are common for estates with hundreds of applications. Google’s published account of its Datacenter Mover project describes roughly two years of phased movement. Any plan that assumes a single cutover weekend for a complex estate should be treated with suspicion.
Can data be moved faster by shipping disks than by network?
Sometimes, yes. At a perfect 100 Gbps, one petabyte takes about 22 hours, and real-world throughput is lower because links are shared and long-distance transfers rarely hit line rate. For very large datasets over constrained links, physical shipping can beat the network. The right choice depends on measured volume and available capacity.
How does GDPR affect where migrated data can live?
The GDPR restricts transfers of personal data outside the European Economic Area and requires a valid legal mechanism for permitted transfers. The 2020 Schrems II judgment invalidated the Privacy Shield, forcing many organizations to rework their arrangements. Migration designs must therefore map data classification to physical location before the target architecture is fixed.
What should a rollback plan include?
A rollback plan should specify the validation checks that trigger a rollback, the time threshold for the decision, the technical steps to restore service from the source environment, and the person with authority to call it. Crucially, it should be rehearsed against real data before cutover, not written and filed. Untested rollback plans fail when they are finally used.
Why is decommissioning part of the migration challenge?
Because migration is not complete until the old environment is securely erased and released. Media sanitization must follow a documented standard, and contracts, interconnects, and asset records need closing out. Organizations that skip this step keep paying for empty space and carry an avoidable data security risk.
