Picture the version of provider-hopping that does not wreck your afternoon. A cheaper H100 shows up on another marketplace, you point one command at it, and a couple of minutes later your box is running on the new provider at the same paths, same virtualenv, same models, right where you left off. No 200-line setup script. No waiting on a 12GB model re-download. You just moved.
That is not how it works today. I build the infrastructure under this stuff, not the models on top, so I will not pretend I have lived your reclaim story. But I spent weeks reading how CLI-native renters actually move a GPU workload to another cloud provider, and the pattern is the same. Moving is not a command, it is a rebuild wearing a migration's clothes. You price-shop across five to ten providers, find the cheaper card, then burn the next 30 to 60 minutes reassembling the environment you already had running somewhere else.
TL;DR: Moving a GPU workload to another cloud provider is easy to start and hard to finish, because the workload is not the files, it is the whole machine: code at its commit, the compiled CUDA environment, system libraries, model weights, and config. Copy the data and you still rebuild the environment on the far side. To move a box without rebuilding it, capture the entire filesystem as a portable snapshot and restore it at the same paths on the new provider.
Why would you move a GPU workload to another provider?
Because the cheapest or most available card is almost never the one you are on right now. Prices swing daily, high-demand SKUs sell out by region, spot boxes get reclaimed with seconds of warning, and better hardware shows up somewhere else. Each of those is a reason to move, and none of them waits for you to be ready.
The single biggest trigger is capacity. A provider you committed to sells out of H100s in your region, gives you no waitlist and no timeline, and suddenly "check back in a few weeks" is the answer to a deadline that will not move. QuantaCloud walks through exactly this failure mode, where a routine capacity event becomes a multi-week fire drill that runs north of $200K for a mid-sized team. Price is the second trigger: the spread between the most and least expensive host for the same hardware can exceed 40 percent. And for the bursty single-GPU crowd, hopping is not occasional. Industry write-ups now describe manually scanning several providers before each job as a survival strategy, not an optimization. One renter put the delta bluntly:
"On Lambda, I was spending around $1,400/month for a mix of A100 and H100 time, averaging about 80 GPU-hours per week. When I moved the same workload to vast.ai, my monthly bill dropped to about $590. Same jobs. Same results." Source: @velinxs, "GPU Cloud Pricing Is a Scam"
Same jobs, same results, less than half the bill. The reason people do not chase that number more often is not that they cannot find the cheaper card. It is that moving to it costs them an hour of rebuild every time.
What actually has to move (the part people underestimate)
Here is where most migration advice goes wrong. It treats the workload as your data and tells you to sync a folder. But the workload that has to arrive intact on the new provider is the whole machine, and it comes in layers:
- Code at its commit. Not
main, the exact commit your run works against, plus any local patches you never pushed. - The Python environment. Not
requirements.txt, the resolved and compiled result of it.torchis pinned to a specific CUDA build and half the wheels compiled locally against the host driver, so re-running the install on a fresh box can silently produce a different environment than the one you tested. - System libraries and drivers. The apt packages, the CUDA toolkit version, the ffmpeg or libGL your pipeline quietly depends on.
- Model weights and data. The 2 to 20GB per checkpoint you pulled from Hugging Face or CivitAI, plus any datasets staged locally.
- Config and secrets. Environment variables, mount paths, the config files you hand-tuned until the thing stopped throwing red errors.
Miss any one layer and the box does not run on the far side. This is the difference between moving your work and moving your machine. A checkpoint file is your work; your machine is that checkpoint plus the two hours of setup that make it runnable. To move a GPU workload to another cloud provider, all five layers have to land at the right paths, or you are rebuilding around whatever showed up.
Why lift-and-shift usually turns into a rebuild
"Lift and shift" implies you pick the workload up whole and set it down whole. On GPU boxes it rarely stays whole, for three concrete reasons.
The first is managed lock-in. On a lot of platforms the thing that made setup convenient is the thing that pins you: their blessed Docker base, their CUDA version, their storage client, their checkpointing API. GPUCloudCompare's procurement breakdown is direct that "managed" often means their driver, their CUDA, their storage client, and your lift-and-shift cost scales with how many of those you adopted. Every hook you leaned on is a rewrite on the way out.
The second is that the same label is not the same hardware. Two instances both listed as "H100 80GB" can differ by 30 percent on throughput, because PCIe and SXM wear the same sticker. Move without checking and your "identical" box runs slower while you hunt a bug that is really a topology change.
The third is data gravity. Your models and datasets have to physically travel, and on the hyperscalers egress is a tax shaped to make that expensive. Moving 10TB of artifacts off AWS runs roughly $900 in transfer fees alone, separate from your GPU bill, which is why teams stay put on uncompetitive compute just to avoid moving data. A network volume does not save you either: it survives a terminate but stays locked to one datacenter and bills while the GPU is off, so it cannot follow you to the cheaper card. I covered that region-lock in the RunPod network volume writeup and what actually makes state portable in this breakdown of cross-provider GPU storage.
Add it up and the veterans have a rule of thumb: on a new provider, budget 2x the compute and 2x the wall-clock time for your first serious run, and call the extra a platform tax. That tax is the reinstall in disguise.
The git-for-GPU-boxes way to move a box
Now flip the framing. You already solved this problem for code. You do not re-type your repo from memory when you switch laptops, you clone it. You version-control your code, your containers, and your infrastructure. The one expensive thing you still rebuild by hand is the GPU box itself.
Treat the box like a repo and moving stops being a project. A snapshot is a commit: freeze the whole machine in a working state. A restore is a checkout: bring that exact state back on a box that has never seen it. The move to another provider becomes a checkout onto different hardware, not a from-scratch reassembly, because the five layers travel together at their real paths instead of getting re-derived on arrival. If you want the mechanics of the snapshot itself, I went deep on snapshotting and restoring a GPU environment across providers. This post is about the move.
The migration, as a checklist
Whatever tool you reach for, the shape of a clean move is the same. The goal is to capture the box, not a slice of it, and to validate the far side before you trust it.
- Inventory the workload. Write down all five layers: the commit, the resolved environment, the system packages, the model and data paths, the config and env vars. If you cannot list them, you cannot move them. This is the step people skip that becomes the 40-minute scramble later.
- Get the box into a known-good state, once. Install, pin the versions that work together, pull the models, confirm it runs end to end. This is the state you never want to rebuild again.
- Capture the whole filesystem, not just the data volume. The snapshot has to include the install at its commit, the environment, the system libraries, and the model files at their real paths. Grab only a models folder and you reassemble the environment around it on the other side.
- Restore onto the target provider at the same paths. This is the step a network volume cannot do, because it will not leave its datacenter. The snapshot lands the full environment on a box that has never seen your setup, so nothing re-downloads from Hugging Face.
- Validate on the new hardware before you trust it. Run
nvidia-smi topo -mto confirm you got the fabric you paid for, check the driver and CUDA versions match what your environment expects, and run one real step of the actual job. Confirm the output matches, then cut over. Keep the old box alive until you have.
None of that is a four-week procurement project. The enterprise "phase it over 8 weeks with parallel runs and rollback" playbook is for fleets of production services. For one renter chasing a cheaper card, the unit of migration is the box, and it should move in one motion.
What breaks when you move across providers
A few honest edges, because this audience has been burned by restore buttons before.
Driver and CUDA compatibility still applies across hardware. Moving between GPU generations can mean a framework rebuild if you were compiled against a specific stack. Restoring the environment removes the setup tax; it does not repeal physics, so validate the CUDA context on arrival.
The same SKU name can mean slower hardware. PCIe versus SXM, HBM3 versus HBM2e, NVLink versus none. Check the topology on the new box instead of assuming the label carried its performance.
The first move pays the egress and sync cost. Large model libraries take real time and money to travel once. The win is that it happens once, not every session; after the first snapshot you are moving bytes you already own instead of re-fetching them at GPU-hour rates.
A restore lands the environment, not a running server. You still relaunch the app once on the far side before you are generating. Better stated here than discovered at 2am.
What you should actually do
Pick by how far and how often you move.
- One provider, one region, forever. You do not have a migration problem. A persistent volume with symlinks solves the re-download tax inside that box. Do not over-engineer it.
- You hop providers to chase price or availability. A volume cannot follow you and a managed host locks you in. You want a provider-agnostic, full-filesystem snapshot that restores the whole environment at its original paths on whatever card you rent next, so a move is a checkout.
- You keep a second provider warm as failover. Inventory the box now, while nothing is on fire, so the snapshot is ready before the capacity alert lands and the move is a one-hour decision, not a fire drill.
The principle under all three is the one git taught you for code. Hard-won state should be a restorable artifact you own and carry, not something you re-derive by hand every time you change providers.
Where this is going
We are building ogre as an open-source standard for exactly this move: a single-binary CLI that snapshots the whole GPU box and restores it on a different provider in one command. It is pre-launch and we are proving it in public, not selling it. The one thing validated end to end so far is a single full round-trip, a real pause then resume that brought back the entire environment, the install at its commit, the venv, the pinned nodes, and a model checkpoint, byte-for-byte on a new box. Cross-provider reliability at scale is the part we are still measuring in the open. "Git for GPU boxes" is the standard we want to get right in public.
About the author
I am on the team at Aquanode. I build the infrastructure under GPU workloads, not the models, so I read the community obsessively instead of speaking for pain I have not lived. What I can speak to is the machine side: we built and validated a full-box snapshot that restores a complete GPU environment on a different box, and we are turning it into an open standard in public.
Sources
- QuantaCloud, "Finding the Cheapest GPU Cloud Does Not Help When Your Provider Sells Out": the capacity-stockout migration trigger and the ~$200K stranded-cost fire drill
- DeployBase, "GPU Cloud Migration Guide: How to Switch Providers": why teams migrate, the 20-40 percent price spread, and the enterprise phased-migration playbook
- GPUCloudCompare, "GPU Cloud Procurement: 15 Pitfalls to Avoid": what "managed" lock-in actually means, the same-label-different-hardware trap, egress math, and the 2x platform tax rule
- Lyceum, "Multi-Cloud GPU Strategy: Avoid AI Vendor Lock-In": data gravity, egress fees as a lock-in tax, and decoupling storage from compute
- @velinxs, "GPU Cloud Pricing Is a Scam": the Lambda-to-vast.ai switching delta, "same jobs, same results"
