Rob Pankow 
Ask a platform team why they have not moved a workload out of the public cloud and you will rarely hear that the application is hard to run elsewhere. Containers are portable, that argument was settled years ago. What you hear instead is some version of: the data is already there.
That is data gravity, and it is the whole problem. A dataset accumulates mass over time. Services attach to it, latency budgets get written around where it sits, and backup and DR runbooks harden into place. Past a certain size the data stops being something you move and starts being something you build around, which is precisely when the exit option quietly disappears.
The useful thing about data gravity is that it is not a mystery force. It is the sum of a few specific, itemisable costs, and almost all of them are decided by one architectural choice made long before anyone drafts an exit plan: what the persistent volumes are made of.
What actually blocks a repatriation, layer by layer
Repatriation gets discussed as one project. It is really four, and they are not remotely equal in difficulty.
| Layer | Portable today? | What the move actually costs |
|---|---|---|
| Compute and containers | Yes | Redeploy against a new cluster, days |
| Networking and load balancing | Mostly | Config rewrite, some redesign |
| Persistent volumes | No | Full copy-out, egress charges, and a rewrite of every StorageClass, snapshot policy and DR runbook |
| Managed data services | No | Re-platform to a self-managed equivalent, plus re-validation |
Table 1: The four layers of a cloud exit, and why only two of them are hard.
The top two rows are why “we are cloud native, so we are portable” feels true and is not. Portability was solved at the compute layer, and the industry has been quietly declaring victory on that basis ever since. The bottom two rows are where repatriation projects actually stall, and the volume layer is the one that compounds, because it gets heavier every day you run.
It is worth being precise about what makes a persistent volume non-portable, because it is three separate things wearing one coat:
- The volume format and API belong to the provider. The volume is not a device you own, it is a service you rent, and it does not exist outside that provider’s control plane.
- The CSI driver is provider-specific. So every StorageClass name, volume snapshot class, topology key and DR runbook you have written is coupled to that driver’s behaviour, not just to Kubernetes.
- Leaving is a metered event. Egress is charged on the way out and not on the way in, which is a pricing structure that does exactly what it is designed to do.
Any one of these is survivable. Together they turn “move the data” into a re-architecture with a bill attached, and that is the estimate that sends repatriation proposals back to committee.
Why the exit cost is set years before the exit
The number that kills these projects is rarely the egress line on its own. It is the total of four things that only become visible once someone does the exercise properly.
There is the egress bill, which is at least predictable if you know your dataset size. There is the dual-running period, where you pay for both sides while the data syncs and the workload is validated, and that period is measured in weeks for anything with a real consistency requirement. There is the engineering time to rewrite storage configuration that was never portable to begin with. And there is re-validation: every recovery-time and recovery-point objective you have committed to was measured against the old storage layer’s behaviour, and none of those numbers carry over.
Notice that only the first of those four is about the size of the data. The other three are about how tightly the storage layer was coupled to one provider, which is a design decision, not a fact of nature. Two organisations with identical datasets can face exit costs an order of magnitude apart.
Is your exit option still real, or has it quietly become theoretical? If the honest answer depends on how much persistent data you are holding in one provider’s volume format, that is worth a conversation before the next renewal. Talk to a storage architect
This also explains why repatriation is discussed far more often than it is executed. The decision point is not the moment the cloud bill becomes uncomfortable. It is the much earlier, much less dramatic moment when someone picks a StorageClass and nobody asks what happens if this workload ever needs to run somewhere else.
Designing for reversibility before you need it
The goal is not to leave the cloud. For most organisations the goal is to be able to, and to be able to run in both places on purpose. That turns a negotiating position into an architecture rather than a threat you cannot execute.
Reversibility at the storage layer means one thing above all: the persistent volumes are served by something that runs the same way on both sides of the move. If the same storage software runs on cloud instance store, on colocation hardware and on your own racks, then the things that made the exit expensive stop applying one by one.
| Storage strategy | Runs in cloud | Runs on-prem | What repatriation becomes |
|---|---|---|---|
| Provider-native block volumes | Yes | No | Full copy-out, egress, and a storage-config rewrite |
| Object storage as the portability layer | Yes | Yes | Cheap to move, but wrong for latency-sensitive stateful workloads |
| Self-managed block storage on NVMe, one CSI driver | Yes, on instance store | Yes | A data sync and a cutover, with configuration unchanged |
Table 2: Three ways to hold persistent data, and what each one turns a cloud exit into.
Simplyblock sits in the third row. The same storage software runs on cloud instances and on your own NVMe hardware, presented through one CSI driver and addressed over NVMe/TCP or NVMe/RoCE. The practical consequence is that your StorageClass names, snapshot semantics and volume re-attachment behaviour are identical in both places, so the runbooks and the RPO and RTO numbers survive the move instead of being rewritten and re-measured against it.
The commercial model follows the same logic. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. There are no capacity tiers, so the storage cost does not change shape when a workload moves between a cloud instance and a dense on-premises node. That matters more than it sounds: a cost model that reprices itself on relocation is its own form of lock-in, because it makes the comparison you need to run untrustworthy.
There is a sovereignty dimension here too, and in Europe it is often the stronger driver of the two. Teams are not usually asking to leave the cloud outright; they are asking to keep specific datasets under a specific jurisdiction while continuing to run everything else where it already runs. That is a placement decision, and it is only available to you if the storage layer can follow the data to a European provider or to your own facility without changing how the workload consumes it. Our overviews of European cloud infrastructure providers and European storage solutions cover that landscape in more detail.
None of this makes the data weightless. A large dataset is still a large dataset, and the first move still has to be paid for. What changes is that you pay it once, as a transfer, rather than paying it again as a re-architecture, and every subsequent placement decision is close to free.
Where to start if the exit option matters to you
Do the exercise before you need the answer, because the answer takes longer to change than to discover.
Start by pricing the exit for one real workload rather than the estimate: the dataset size and its egress cost, the dual-running window, the storage configuration that would have to be rewritten, and the recovery objectives that would have to be re-measured. That number is the true strength of your negotiating position, and most teams find it is considerably worse than they assumed.
Then separate your stateful workloads into the ones that genuinely need to sit next to a provider-managed service and the ones that are on provider-native volumes only because that was the default when they were deployed. The second group is usually much larger, and it is where reversibility is cheap to buy. The economics behind why these bills grow the way they do are covered in our post on cloud exit economics, and the mechanics of moving block devices without downtime in our guide to avoiding storage lock-in.
The teams that end up with a real choice are not the ones that predicted their cloud bill correctly. They are the ones that kept the persistent data in a format they could pick up and carry.
Questions and Answers
What is cloud repatriation?
Cloud repatriation is moving workloads and their data out of the public cloud, usually to on-premises hardware, colocation, or a smaller regional provider. It is driven by cost at scale, by predictability, and increasingly by data sovereignty requirements. The compute side is straightforward for containerised workloads; the difficulty is almost always the persistent data and the managed services attached to it.
What is data gravity and why does it block a cloud exit?
Data gravity describes how a dataset attracts services and applications toward it, so that moving the data means moving everything built around it. In practice it is a set of concrete costs: egress charges, a dual-running period while data syncs and the workload is validated, rewriting storage configuration coupled to a provider-specific CSI driver, and re-measuring every recovery objective. Only the first of those scales with dataset size. The rest scale with how tightly the storage layer was coupled to one provider.
How much does cloud repatriation actually cost?
Budget four items, not one. Egress on the dataset, which is predictable if you know its size. The dual-running window, typically weeks for anything with a real consistency requirement. Engineering time to rewrite StorageClasses, snapshot policies and DR runbooks. And re-validation of RPO and RTO commitments against the new storage layer. Two organisations with identical datasets can be an order of magnitude apart on the last three, entirely because of storage design choices made years earlier.
Can I avoid storage lock-in without leaving the cloud?
Yes, and that is usually the more sensible goal. Running self-managed block storage on cloud instance store, presented through the same CSI driver you would use on your own hardware, keeps StorageClass names, snapshot semantics and re-attachment behaviour identical in both places. You stay where you are, but relocation becomes a data sync and a cutover rather than a re-architecture, which is what makes the option real rather than theoretical.
How does simplyblock help with cloud repatriation?
Simplyblock runs the same storage software on cloud instances and on your own NVMe hardware, addressed over NVMe/TCP or NVMe/RoCE through a single CSI driver, so persistent volumes are not tied to one provider’s volume format or control plane. Configuration, snapshot behaviour and recovery objectives carry across unchanged, which removes three of the four cost items above and leaves only the one-time transfer. Licensing follows the platform rather than a capacity tier, so the cost model does not reprice itself when a workload moves.
