The switching cost is the integration, not the contract
Three months is a common figure for moving from one provider to another, and the hardware is rarely why. API shape, model artifact formats and monitoring systems force a rewrite that has nothing to do with the silicon underneath.
Deciding to migrate takes longer than migrating. The common pattern is six months of deliberation ahead of a four-week execution, which means the delay is organisational rather than technical.
GPU quota approval on the receiving side usually sets the critical path. That is a scheduling dependency rather than an engineering one, and it is worth starting before anything else.
47 seconds
of compute time lost moving 10,000 GPUs between facilities, against an average of 72 hours for migrations that were not planned in advance
Meta 2023 facility consolidation, via Introl zero-downtime migration analysis
◆ PREPARATION RATIO
Three hours of planning per hour of execution
A 48-hour physical migration needs roughly 144 hours of preparation to land at zero downtime. That three-to-one ratio is the gap between the 47-second outcome and the 72-hour one, and it is almost entirely front-loaded work.
Around 83% of migrations experience some disruption. The ones that do not are not luckier, they are the ones where the dry run happened before the cutover rather than instead of it.
◆ THE PARALLEL-RUN PATTERN
Cutover is not the last step
Route 5% of traffic to the new provider, then 25%, then 50%, then 100%. That part is familiar. The part teams skip is what comes after.
Keep the old provider running in shadow mode for two weeks past full cutover. Send every request to both, compare responses, and log discrepancies. Decommission only after that window closes clean.
Run dual monitoring across both providers for two to four weeks as well. A single cutover test catches obvious breakage. It does not catch slow drift in quality or latency, which is the failure mode that surfaces as user complaints weeks later.
◆ WHAT MAKES A MIGRATION REVERSIBLE
Keep the old contract running past the date you need it
Shadow mode only works if the old environment is still paid for. A contract that ends on the cutover date removes the rollback option precisely when it is most likely to be needed, and overlapping the two by four to six weeks costs a fraction of what an emergency re-migration does.
Reversibility also depends on what moved. Stateless serving can be rolled back by changing a routing weight. Anything holding training state cannot, which is why statefulness rather than importance should decide migration order.
◆ COLD CLUSTERS ARE SLOW CLUSTERS
No cached embeddings, no warmed kernels
A newly provisioned cluster starts cold. Nothing is cached, no kernels are warmed, and the first requests through it will not represent steady-state performance. Sending 100 to 500 warmup requests before routing live traffic avoids reading that as a regression.
Weight loading is the other cold-start cost. Storage read bandwidth on the target determines how long 100GB-plus of weights take to reach GPU memory, so a local NVMe cache and pre-warmed nodes matter more during a migration than they do in steady state.
◆ WHERE PERFORMANCE QUIETLY DROPS
Interconnect and driver differences
Multi-GPU tensor-parallel serving can lose throughput if the target fabric differs from the source. All-reduce time is the metric that exposes it. Confirming the interconnect tier before committing, and keeping models single-node where the memory allows, removes most of that risk. The mechanics are covered in InfiniBand vs Ethernet.
NVLink topology, NIC bandwidth and driver versions all move inference throughput independently of the GPU model. Benchmarking on the target with your own load tests, rather than comparing spec sheets, is what catches those before cutover.
◆ THE DATA LAYER
Bulk sync early, delta sync at cutover
Sync the primary dataset to the target well ahead of cutover using rclone or an equivalent, then run a final delta sync immediately before switching traffic. Waived egress fees do not make petabytes move faster, and transfer time is the part that cannot be compressed on the day.
Order the migration by statefulness. Stateless inference serving goes first because it is reversible, and anything carrying training state goes last because it is not.
Zero downtime is not a property of the migration. It is a property of how much of the work happened before the migration started, and the teams reporting 47 seconds rather than 72 hours did the same steps in a different order.
The practical sequence: start the quota request first, benchmark the target with your own load tests, bulk sync the data, canary through 5, 25, 50 and 100%, shadow the old provider for two weeks, then decommission.
Get quoted before the quota request, not after.
Capacity confirmed against your spec, so the critical path starts early. No buyer fees. For single GPUs, packet.ai handles self-serve access with 24/7 human support.
A containerised stateless endpoint takes two to four hours. A single-model inference service runs about four weeks, and a multi-model fleet eight to twelve. Weight and dataset transfer runs days to weeks depending on egress bandwidth.
Yes, with preparation. One documented facility consolidation moved 10,000 GPUs losing 47 seconds of compute. The ratio behind that is roughly three hours of preparation per hour of execution, against an average of 72 hours downtime on unplanned migrations.
Two weeks after full cutover, not at cutover. Run the old provider in shadow mode, send every request to both, compare responses and log discrepancies. Keep dual monitoring for two to four weeks to catch slow drift in quality or latency.
Because it is cold. No cached embeddings, no warmed kernels, and weights still loading from storage. Sending 100 to 500 warmup requests before routing live traffic prevents that being read as a performance regression.
GPU quota approval on the receiving side, which is a scheduling dependency rather than an engineering one. Start it before anything else. After that, integration rewrite and per-model validation dominate, not the hardware itself.
Last reviewed: 29 September 2026. Migration durations, quota critical path, interconnect and storage risk factors from Qovery's GPU inference migration playbook, October 2026. The 10,000-GPU facility consolidation figure, preparation ratio and disruption rate from Introl's zero-downtime data centre migration analysis, March 2026. Parallel-run staging, shadow mode, warmup request counts and dual monitoring windows from GMI Cloud's inference provider switching guide, April 2026. Stateless endpoint timing and benchmarking guidance from Spheron's GPU cloud egress and migration checklist, August 2026. Data sync sequencing from Lyceum Technology's dedicated GPU migration guide. Browse current GPU cluster availability on GPUaaS.com.
