This piece is written for decision-makers and the people who brief them. The technical detail is intentional; sovereignty arguments that don't show their working shouldn't be trusted.
On 1 April 2026, my hosting provider raised prices by 30%. No warning. No service improvement. No explanation beyond a line in an invoice. Same workload, same usage, same infrastructure; just a different number at the bottom.
For a large organisation with a finance team and an approved vendor list, that invoice probably got processed without comment. For a self-funded operation, it is a different conversation. That 30% is not an abstraction; it is a tool renewal, a software licence, a portion of a contractor day. It lands.
So we looked at it. And looking at it properly meant asking a question that organisations rarely ask until something forces them to: do we actually know what we are paying for, who holds it, and what it would take to move?
The answer, it turned out, was illuminating. Not because the infrastructure was a mess; it was not. But because the process of asking the question exposed assumptions that had never been written down. Jurisdiction. Control plane dependencies. What "backed up" actually means when the provider controls the storage layer. Whether the DR plan survives the provider, not just the failure.
The price increase was the trigger. The sovereignty audit was the result.
Most organisations do not move. The economics can be obvious, the alternative documented, the risk arguable; and still nothing happens.
Three defences get deployed, usually in combination.
The first is complexity. Migration is hard, the argument goes. There are dependencies, integrations, staff time. The implicit calculation is that the cost of moving outweighs the cost of staying. That calculation is rarely done rigorously; it is a feeling, formalised after the fact.
The second is risk aversion; but selectively applied. Something could go wrong during migration. That risk is visible, attributable, and lands on someone's desk. The risk of staying; vendor dependency deepening, jurisdictional exposure accumulating, pricing power transferring quietly to the supplier; is diffuse and deniable. Boards and procurement committees are structurally better at saying no to visible risk than at pricing invisible risk. Vendors understand this. Their lock-in strategies are built around it.
The third is the vendor's own narrative. Providers have invested heavily in making migration to them feel frictionless. Migration away is a different experience. The tooling, the documentation, the account management; all of it points inward. That asymmetry is not accidental and it is not neutral.
None of this means migration is always right. But stasis has a risk profile too; one that compounds quietly until something external forces the question. A price increase. A regulatory change. An acquisition that moves your data under a different legal jurisdiction without a single configuration change on your side.
There is a fourth defence that rarely gets named because it is uncomfortable: the skills are gone. Not the will, not the budget; the capability. A decade of hyperscaler abstraction has produced infrastructure teams of genuine depth and genuine narrowness. They can declare any state imaginable in Terraform. They cannot always build a clean server. That is not a failure of individuals; it is a structural consequence of how the industry consolidated. It is also, quietly, the most durable form of lock-in.
The CFO reading this should sit with that for a moment. That £500,000 infrastructure bill may be partly paying for a team that could not migrate away even if the board instructed it to.
The organisations that move on their own terms do so because they chose the moment. The ones that move under pressure rarely get to choose anything.
"Sovereignty" gets used a lot these days; and it also gets used very loosely. In infrastructure conversations it tends to mean one of two things: either a vague preference for European providers, or a compliance checkbox confirming that data does not leave a particular geography. Neither is wrong, but neither is sufficient.
Data residency is where your data sits. Data sovereignty is who can reach it, under what legal authority, and whether you would know if they did.
A server in Frankfurt operated by a US-headquartered company is not sovereign infrastructure. The data may never physically leave Germany. But the company that operates it is subject to US law; including the CLOUD Act, which allows US authorities to compel disclosure of data held overseas by US providers without involving the host country's legal system. The Frankfurt address is a comfort, not a guarantee.
This distinction matters practically, not just theoretically. If you operate under UK GDPR, Isle of Man GDPR, or are advising clients who do, your data processor's legal jurisdiction is a material fact. It belongs in your DPIA. It belongs in your vendor assessment. It is not answered by a data centre map on a marketing page.
Sovereign migration, properly understood, means moving to infrastructure where the provider is headquartered and legally domiciled outside US jurisdiction; the data centre is within EEA or equivalent recognised adequacy territory; the control plane; the management layer, the API, the billing system; is not routed through a US entity; and your DR and backup targets meet the same standard, not just your primary.
That last point catches people. An EEA primary node backed up to an S3 bucket operated by a US company is not a sovereign architecture. The backup is the recovery path. If the recovery path is compromised, the sovereignty of the primary is academic.
Once you have the constraints, the decision space shrinks considerably. That is the counterintuitive thing about sovereignty requirements; they feel like they add complexity, but applied correctly they eliminate options quickly and cleanly.
Our constraint was simple: EEA or Swiss jurisdiction throughout, no US cloud exposure at any layer, no CLOUD Act or FISA 702 risk at any point in the stack. That ruled out DigitalOcean immediately; US-headquartered regardless of which data centre you select. It ruled out any provider whose parent company, billing entity, or control plane sits outside the acceptable territory. The list of candidates was shorter than the marketing landscape suggests.
What remained was evaluated against three practical criteria: hardware specification relative to actual workload, cost at realistic utilisation, and operational maturity; meaning whether the provider has been running infrastructure long enough to have a track record worth reading.
The workload audit came first. Current RAM usage: 5.4GB of 15GB available. Database on disk: 15GB, compressed backup 2.84GB, growing at roughly 100MB per week. That is a well-understood, modest footprint. The temptation in these exercises is to overspec the target "just in case." Resist it. Overspeccing is how migration costs balloon and how the CFO stops listening.
Netcup's RS 2000 G12; eight dedicated AMD EPYC 9645 cores, 16GB DDR5 ECC RAM, 512GB NVMe, DE/AT jurisdiction; came in at €18 per month. Infomaniak in Switzerland for object storage at approximately €4 per month. OVHcloud Gravelines in France already existed as the DR mirror and NIS2 fallback, and was retained; repointed rather than rebuilt.
One sovereignty footnote worth stating explicitly: Netcup now operates a Virginia deployment zone. DE/AT must be selected explicitly at provisioning. The default is not always the sovereign option; read the provisioning screen.
Total target stack: €22.12 per month. Equivalent or better specification throughout. Zero US exposure. All within EEA or Swiss jurisdiction. The decision took an afternoon. The migration took longer. That is the correct ratio.
The migration itself was not dramatic. That was deliberate.
The principle is simple: the new environment must be fully operational, restore-tested, and verified before anything is cut over. DNS change is the last step, not the first. The temptation to "just point it over and see" is how you end up doing a post-incident review at 03:15 on a Tuesday.
The sequence ran as follows.
First, a complete configuration harvest from the live node. Every environment file, every reverse proxy configuration, every scheduled task, every container definition. Committed via signed commits to a private repository before a single change was made to the source system. If the migration had stopped at that point, the harvest alone would have had value; a documented, version-controlled snapshot of what production actually looked like, not what anyone remembered it looking like.
Second, the target node was provisioned and hardened from scratch. Not cloned, not snapshotted; built clean. Firewall rules, VPN access, intrusion prevention, SSH key authentication with password authentication disabled. The discipline of building clean rather than copying state means you know what is on the new node. Copying state means you inherit whatever accumulated entropy existed on the old one.
Third, services were rebuilt in dependency order. Database first. Object storage connectivity verified before the application layer. Application layer configured and tested before any external traffic. Each layer signed off before the next began.
One practical note: Linux distribution package repositories for some dependencies lag behind what current application versions require. In this case, a media processing library was only available at an older version in the standard repos; the application required a more recent release. Build from source, verify the version, move on. These are the details that do not appear in migration guides and do appear in production incidents.
Fourth, the DR target was repointed. The existing off-site mirror was updated to point at the new node rather than the old one. This was done and verified before DNS cutover. At no point was the organisation running without a tested recovery path.
Fifth, DNS TTL was reduced well in advance; to 300 seconds; giving a narrow rollback window at cutover. The original node was kept live and traffic-capable throughout, acting as a bridge proxy during the propagation window. Rollback was a DNS change, not a rebuild.
Cutover happened when everything on the checklist was green. Not before.
The whole process is boring to describe. It was boring to execute. That is the correct outcome. Infrastructure migrations should be boring; excitement in this context is a symptom, not a feature.
Here are the actual figures.
Before migration: shared-core VPS, Helsinki. Monthly invoice prior to April 2026: €40.27. Post-increase invoice: €52.98. Increase: approximately 30%. No change in workload, no change in usage, no change in specification.
After migration: dedicated-core root server, Nuremberg. €18.00 per month. Object storage, Switzerland: approximately €4.12 per month at current utilisation. DR mirror, France: retained on existing credit at approximately €3 per month burn rate.
Total post-migration monthly cost: approximately €22 per month.
Annual saving against the post-increase figure: approximately €370.
The new hardware is not a downgrade. Eight dedicated EPYC 9645 cores against a shared-core predecessor. 16GB DDR5 ECC RAM. 512GB NVMe. The cost reduction and the specification improvement arrived together; which is not always the case, but reflects the maturity of the European sovereign hosting market in 2026.
No US cloud exposure at any layer. No CLOUD Act risk. No FISA 702 risk. Full EEA and Swiss jurisdiction throughout. Zero regression on the sovereignty posture.
The CFO number is €370 per year. The compliance number is a DPIA that does not require a footnote explaining why a US provider is in the supply chain. Both matter. In most organisations, the CFO number is what gets the meeting.
If your role is to convince rather than execute, the argument has three layers. Sequence matters.
Lead with money.
A 30% price increase on infrastructure that has not changed is not a supplier relationship; it is a dependency being monetised. The question for the CFO is not whether you can afford to move. It is who controls the cost of staying, and what leverage you have over that number. The answer, under most enterprise cloud contracts, is less than you would like.
The figures in this piece are not exceptional; €370 per year is not material at scale. But the methodology is. Apply the same exercise to a £500,000 per year infrastructure commitment and the conversation changes entirely. The saving funds the migration and then some. More importantly, it reframes the relationship: you are a customer with options, not a tenant without alternatives.
Then introduce jurisdiction; as legal exposure, not ideology.
Your organisation has data protection obligations. Under UK GDPR, Isle of Man GDPR, or equivalent frameworks, your processor's legal jurisdiction is a material fact. A US-headquartered provider operating a Frankfurt data centre is still subject to US law. The CLOUD Act; in force since 2018; allows US authorities to compel disclosure of data held overseas by US providers, without involving the host country's legal system and without necessarily notifying either the data controller or the data subject.
The question for your legal team and your board is straightforward: is this documented in your DPIA? If not, it should be. If it is, the next question is whether the risk is accepted, mitigated, or transferred; and what the audit trail looks like. Under an accountability-based regime, undocumented risk is not a neutral position; it is a liability waiting for a context.
Finally, reframe the risk comparison.
The objection to migration is always risk. But the comparison is not migration risk versus zero risk. It is migration risk versus the compounding risk of inaction; vendor repricing, deepening lock-in, jurisdictional exposure, and the possibility that the forcing function arrives in a form less manageable than a price increase.
The organisation that migrates on its own timeline, with a tested runbook and a parallel environment, is in a materially different position from the organisation that migrates under regulatory pressure or following an incident. Both will eventually move. The board should ask which scenario they are currently planning for.
Credibility requires honesty about the friction, not just the outcome.
The configuration harvest should have been done earlier and more formally. Not as a migration prerequisite but as an operational baseline. Knowing exactly what is running, where, with what configuration, should not require a migration to force the discipline. If your answer to "what does production actually look like right now" is "roughly like this" rather than a signed, version-controlled document, that is a gap worth closing independent of any migration plan.
The dependency audit took longer than it should have. Some library versions, some service interdependencies, some scheduled task interactions were not fully documented before the build began. They were discovered during it. None were fatal; some were avoidable with better upfront inventory.
Build time for compiled dependencies is not something migration guides tend to account for. It is not long; but it is not zero, and if you are working to a maintenance window it belongs in the timeline.
DNS TTL reduction should happen earlier than feels necessary. Seventy-two hours before intended cutover is not excessive. DNS propagation behaviour in practice does not always match the theoretical model, and a narrow TTL window at the moment you want it is worth more than a standard TTL you forgot to change.
And one observation that applies beyond this migration: the organisations that find this process hardest are not the ones with the most complex infrastructure. They are the ones with the least documented infrastructure. Complexity can be managed; undocumented complexity cannot; at least not quickly, and not calmly.
One counter-argument deserves an honest answer rather than a footnote: labour cost. Sovereign bare metal puts database replication, storage management, and hardware failure response back in human hands. At genuine enterprise scale, with complex multi-region workloads, that is a real cost and it belongs in the migration business case. But organisations should be precise about what they are actually buying from managed services; genuine capability they could not otherwise afford, or a subscription compensating for institutional knowledge they allowed to atrophy. The answer changes the economics considerably. In most cases, honest examination reveals it is more of the latter than the former.
The migration works. The numbers are real. The sovereignty posture is intact. But the most valuable output of the exercise was not the new server. It was the complete, signed, version-controlled picture of what production actually looks like; which now exists, and did not before.
That alone was worth the invoice.
The Sovereign Auditor covers supply chain security, digital sovereignty, and infrastructure policy—with particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.
