Rob Pankow 
A VMware® exit gets planned as a platform decision and costed as a licensing decision. Sovereignty usually shows up once, as a slide in the business case, and then vanishes into the architecture phase where it is treated as somebody else’s workstream.
It does not vanish. It relocates. Jurisdiction is not a property of the platform you pick, it is a property of the data plane underneath it: where bytes are written, where copies of them go, who holds the keys, and who can be asked to hand any of it over. On vSphere most of those questions had answers nobody had to write down, because a vSAN cluster placed its replicas inside hardware you owned, in a room you could point at. The answers were correct by accident of topology.
The migration re-opens every one of them, and this is the part that catches teams out: the new answers are mostly supplied by defaults rather than by people. A StorageClass that spreads replicas across zones for availability is doing exactly what it was designed to do, and it may be crossing a boundary that vSAN never crossed. This post is the storage-plane list. It is deliberately narrow. For the governance model, the audit programme, and the rollout sequencing, the existing sovereignty-by-design guide covers that ground and this post does not re-argue it.
Residency, sovereignty, and localization are not the same requirement
Teams use the three words interchangeably in planning documents and then discover, halfway through a design review, that they were solving different problems. The distinction matters because each one constrains a different part of the stack.
| Requirement | What it constrains | What it asks of the architecture | Typical evidence |
|---|---|---|---|
| Data residency | The physical location where data is stored and processed | Placement rules you can express, enforce, and prove for primary data and every copy | Region and site attestation, replica topology, backup target locations |
| Data sovereignty | Which legal system, and which parties, can reach the data | Custody of keys and credentials, and the jurisdictions of every party who holds them | Key management ownership, operator access model, support and telemetry paths |
| Data localization | A legal obligation to keep specified data inside a border | The above, plus a hard prohibition rather than a preference, usually with no failover exception | Named-jurisdiction contracts, documented exceptions, incident procedures |
Residency is a geography question and it is the easiest of the three to satisfy and to audit. Sovereignty is a control question, and an architecture can be perfectly resident and not sovereign: data sitting on disks in Frankfurt, encrypted with keys held by a managed service under a different legal regime, is inside the border and outside your control. Localization is residency with the escape hatches removed, which is why it tends to break disaster recovery designs rather than primary ones.
Regulation is what makes the distinction expensive. The GDPR concerns itself with transfers of personal data and with who is accountable for them. The US CLOUD Act is the reason European buyers now ask who can be compelled to produce data rather than only where the bytes sit. Whether either applies to a specific arrangement is a question for counsel, and nothing in this post is a legal conclusion. The architecture question underneath them is narrower and genuinely answerable by an infrastructure team: which organisations hold credentials to the data plane, where are those organisations incorporated, and can you demonstrate the answer without a spreadsheet built by hand.
The six jurisdiction decisions a migration re-opens
Here is the working list. Every row was decided implicitly on vSphere and is decided explicitly, or by default, on the other side.
| Decision | What vSphere or vSAN decided | Destination default | Can the default cross a boundary | Visible in an audit |
|---|---|---|---|---|
| Replica placement | Storage policy placed component replicas across fault domains inside one cluster you owned | Topology-aware provisioning spreads replicas across whatever zones the cluster advertises | Yes, if a zone maps to another region or another operator’s site | Only if topology labels are meaningful and reviewed |
| Snapshot and backup target | Backups landed on a named datastore or an appliance in the same room | An object storage bucket, whose region is set once at creation and rarely re-read | Yes, and this is the most common silent crossing | Rarely, the bucket region is not in the Kubernetes objects |
| Key custody | Keys sat with the storage or backup product inside the estate | Whatever key service the platform or cloud offers, often managed | Yes, custody can leave the boundary while the data does not | Partly, key ownership is usually documented but not tested |
| Operator and support access | A named internal team, plus vendor support under an existing contract | Vendor and platform support paths, which may include remote data-plane access | Yes, access is a boundary crossing even when data does not move | Almost never, support access is a contract artifact, not a config |
| Telemetry and observability export | Metrics stayed with vCenter and the on-site monitoring stack | Managed observability endpoints, frequently outside the region | Yes, and payloads can carry more than metrics | Rarely, exporters are configured once and forgotten |
| DR site location | An explicitly contracted second site | A second zone or region chosen for latency and cost | Yes, DR is where localization requirements break first | Usually yes, DR sites tend to be documented |
Replica placement. On vSAN, a failures-to-tolerate policy distributed components across fault domains within a cluster, and the cluster was a set of machines with a postal address. In Kubernetes the equivalent lever is topology: a StorageClass can restrict provisioning with allowedTopologies, and volumeBindingMode: WaitForFirstConsumer defers the placement decision until a pod is actually scheduled. Both are opt-in. The default behaviour is to use whatever topology labels the cluster carries, and those labels are usually set by whoever built the cluster, for availability reasons, months before anyone asked a jurisdiction question. A three-zone spread is a good availability design and a boundary crossing at the same time, and neither property is visible from the PVC.
Snapshot and backup targets. This is the row that breaks quietly and the one worth checking first. The exit typically replaces a datastore-level backup chain with an object storage target, because that is what the Kubernetes-native tooling expects. A bucket has a region, that region is chosen at creation, and from that point on it appears nowhere in the manifests a platform team reviews. The backup estate replacement post covers what happens to the chain itself; the jurisdiction point is separate and simpler: the copy is the thing regulators care about, and the copy is the thing your storage design stops tracking the moment it leaves the block layer.
Key custody. Encryption at rest is not the interesting question, since every serious option offers it. Custody is. Self-hosted key management keeps custody inside the boundary and costs you an operational service to run. A managed key service is easier and moves custody to whoever operates it. That is a legitimate trade in many estates and an unacceptable one in a few, and it should be a recorded decision rather than the byproduct of which platform was easiest to bootstrap. The Vault KMS integration walkthrough covers the self-hosted path in detail, including why auditors care that the team running the key service is not the team running the storage cluster.
Operator and support access. Data does not have to move for a boundary to be crossed. If a vendor can open a remote session into the data plane to diagnose a problem, that access path is part of the sovereignty boundary, and it is the part that never appears in an architecture diagram. It is also the reason platform vendors have started selling jurisdiction-scoped support tiers as products. Whatever you choose, write down which parties can reach the data plane, under what contract, and from where.
Telemetry and observability export. Metrics endpoints get configured during the build phase, by people optimising for time to first dashboard, and are almost never revisited. Two questions settle this row: where does the endpoint terminate, and what is actually in the payload. Metrics are usually harmless; logs and traces frequently are not.
DR site location. DR is where a localization requirement meets an availability requirement and one of them loses. A second site chosen for latency and cost may be in the wrong jurisdiction, and the failover event is precisely when nobody is going to stop and check. Decide this one at design time or it gets decided for you at the worst possible moment.
Jurisdiction is an architecture property, not a procurement checkbox. If your exit plan does not yet state where replicas, snapshots, and keys land, that is the conversation to have before the first cutover wave rather than after it. Talk to a storage architect
Making placement explicit instead of inherited
The useful reframe is this: the platform decision and the storage decision are separable, so the jurisdiction decision does not have to be inherited from whichever hypervisor replacement you land on. Red Hat® OpenShift® Virtualization, plain KubeVirt, and bare-metal Kubernetes all leave the storage layer as an independent choice, and that independence is the lever.
Four things make the six rows above explicit rather than emergent.
Put the topology constraint in the StorageClass, not in a runbook. allowedTopologies is a machine-readable statement of a jurisdiction rule. A runbook is not. If a class is only permitted to provision in one set of zones, the constraint is enforced by the provisioner and it is reviewable in Git, which is the same evidence an auditor wants.
Make the replication target a named decision. Replication that happens because a default said so is the failure mode. Simplyblock configures a replication target explicitly per volume, a second availability zone or a second cluster in a named physical location, so the second copy has an owner and an address rather than a policy side effect. The Day 2 operations post covers the mechanics of that path.
Keep the keys where the policy says they belong. HashiCorp Vault and OpenBao are the supported key management backends for simplyblock, which keeps custody with a service your organisation runs, under separate administrative control from the storage cluster. That separation is what turns a claim into evidence.
Keep the data plane on hardware you can point at. Simplyblock runs on your own NVMe hardware in your own facility or in a provider you have contracted with, pooled over an NVMe/TCP or NVMe/RoCE fabric. The bytes do not leave the boundary because there is nowhere else for them to go, which is a duller and more durable guarantee than a policy setting. This is the same argument that applies to European providers running regional platforms: the storage layer sits on their infrastructure as a peer to it, not as a service reaching in from somewhere else. Providers running a multi-tenant estate should also read the service provider exit post, where jurisdiction becomes a per-customer commitment rather than a per-estate one.
Licensing is worth one sentence here because it interacts with the design. 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. A capacity-tiered model quietly pushes estates toward consolidation, and consolidation is the enemy of explicit placement.
What the storage layer does not fix
The claim in this post is narrow on purpose, and it is worth stating the limits plainly because this is the pillar’s highest-risk subject matter.
Simplyblock is not a compliance product. It does not make an organisation GDPR-compliant, it does not produce a legal opinion, and it cannot tell you whether a given transfer is lawful. Those remain questions for your legal and compliance functions, and any vendor implying otherwise is selling something it cannot deliver.
It also cannot fix the layers around it. A sovereign data plane under a control plane operated from another jurisdiction is not a sovereign system. Nor is one whose identity provider, CI pipeline, or ticketing system sits outside the boundary, and those are frequently the paths an assessor asks about first. If backups land in a bucket in the wrong region, no property of the block layer underneath rescues that. The datastore replacement post makes a related point about capacity habits, and the same logic applies here: the storage layer answers the questions in its own scope and is silent on the rest.
What it does do is remove one class of accidental boundary crossing. Replica placement, second-copy location, and key custody stop being defaults and become recorded decisions with owners. For most estates leaving vSphere that is three of the six rows closed by architecture rather than by policy, which is a smaller claim than the market usually makes and a considerably more honest one.
Questions and Answers
What are the data residency requirements a VMware migration actually changes?
Six of them, all in the storage layer: replica placement, snapshot and backup target location, key custody, operator and support access to the data plane, telemetry export destinations, and DR site location. On vSphere each was answered implicitly by the fact that a vSAN cluster lived in hardware you owned. After the migration each is answered by a default unless someone makes it a decision, and defaults are optimised for availability and cost rather than for jurisdiction.
Is data residency the same thing as data sovereignty?
No, and conflating them is the most common planning error in this area. Residency is about where data physically sits, and it is satisfied by placement rules you can enforce and prove. Sovereignty is about which legal system and which parties can reach the data, and it is satisfied by controlling keys, credentials, and access paths. An estate can be fully resident and not sovereign: disks in the right country, keys held by an operator in the wrong one.
How does simplyblock help with data sovereignty requirements?
Simplyblock keeps the data plane on your own NVMe hardware inside your boundary, makes replica and replication-target placement an explicit per-volume decision rather than a topology default, and supports self-hosted key management through Vault or OpenBao so key custody stays under your administrative control. It is also chosen independently of the hypervisor replacement, so the jurisdiction decision is not inherited from the platform vendor. It is not a compliance product and does not make an organisation compliant on its own.
Which storage decision most often breaks residency without anyone noticing?
The backup target. A migration usually swaps a datastore-level backup chain for an object storage bucket, the bucket’s region is chosen once at creation, and after that it appears nowhere in the Kubernetes objects a platform team reviews. The primary data stays exactly where the design intended while the copies quietly do not, and copies are what regulators ask about.
Can a Kubernetes StorageClass enforce a jurisdiction boundary?
Partly, and it is the best mechanism available at that layer. allowedTopologies restricts which zones a volume may be provisioned into, and volumeBindingMode: WaitForFirstConsumer defers binding until a pod is scheduled so placement follows the workload. Both are machine-readable and reviewable in Git, which makes them usable as audit evidence. Neither covers backup targets, key custody, or support access, so a StorageClass is one control among several rather than the whole answer.
Does keeping storage on-premises make an estate sovereign by itself?
No. It closes the data-plane rows and leaves the control-plane rows open. If the management plane, identity provider, or observability stack is operated from another jurisdiction, the system as a whole is not sovereign regardless of where the disks are. On-premises or contracted regional storage is a necessary component of a sovereign design and not a sufficient one.
