The sovereign cloud movement is forcing a question the industry has been avoiding. When you have to move off a hyperscaler, the bottleneck isn't the new provider's APIs. It's how precisely you can express what you actually need. Intent is becoming the architecture that matters most.
The sovereign cloud movement is no longer a policy discussion. It's a procurement decision. Gartner projects $80 billion in sovereign cloud IaaS spending worldwide this year, and European spending is growing at 83% year-over-year. The EU is actively legislating where sensitive data can be processed and by whom, through the Data Act, the EUCS certification scheme, and the proposed Cloud and AI Development Act. France requires European-operated cloud services for public institutions and critical infrastructure. German governments, from the state of Schleswig-Holstein to the federal chancellery, are migrating off Microsoft 365.
The driver isn't ideology. It's the US CLOUD Act. Under current law, US agencies can access data stored in US-owned data centres abroad. For European organisations handling financial, health, or judicial data, that's not an acceptable risk. The decision to move is increasingly not optional.
And it has nothing to do with whether AWS is a good product.
The migration problem #
Here's what moving off a hyperscaler actually looks like today.
Your Terraform modules are written against the AWS provider. Your Helm charts reference AWS-specific annotations. Your CI pipelines assume AWS credentials. Your monitoring is wired to CloudWatch. Your team's operational knowledge is built around AWS primitives.
Moving to a European provider — Elastx, OVHcloud, IONOS, Scalway, any of them — means rewriting. Not refactoring. Rewriting. New provider, new resource models, new naming, new quirks. The 200% problem: you learn the tool's abstraction and you learn the underlying API. Moving providers means paying that tax again from scratch.
This is why multi-cloud has been a punchline for a decade. Your automation is coupled to your provider. Changing providers means rewriting your automation, and that rewrite delivers zero new functionality. It's months of engineering work just to end up where you started, on a different API.
The decision is human, the execution shouldn't be #
The decision to pursue sovereign cloud is strategic. It requires understanding your regulatory obligations, your data residency constraints, your risk tolerance, your operational requirements. No agent makes that call for you.
But once you've made that decision, the execution shouldn't require rewriting everything from scratch. The intent is clear: I need my infrastructure to run on a European provider, under European jurisdiction, with my data staying in-region.
Today, getting there means a team of engineers spending months learning a new provider's APIs, rewriting modules, testing migrations, discovering edge cases the documentation doesn't mention. The knowledge required is real, but most of it is mechanical translation — turning what you want into however a specific provider delivers it. That's where the time goes, and it's exactly the kind of work that agents with the right structure handle well.
Intent as the design document #
I've been thinking about what changes when agents execute against typed schemas rather than generating code. Speed is the obvious part. The less obvious part is that the engineering work shifts. You stop spending time on provider-specific implementation and start spending it on getting the intent right. What do you actually need? How specifically can you describe it?
"Move us off AWS" is a direction. It's not intent.
"I need our Kubernetes workloads running on Elastx's managed Kubernetes in Stockholm. Data must stay in EU jurisdiction. We need equivalent monitoring through a European observability provider. The migration should be staged: non-production first, production after validation. Downtime tolerance is zero for the payment service, one hour maintenance window for internal tools." That's intent. And it's precise enough that an agent with the right extensions can reason about what exists, what needs to change, and in what order.
The gap between those two statements is where most migration projects stall. Closing it is the actual engineering work now.
This is what we're building swamp to enable. Typed extensions that describe what any system can do, agents that reason against those schemas, and deterministic execution that produces the same result every run. The agent handles the mechanical translation. You focus on expressing what you actually need.
The skill shift #
For a decade, the most valuable infrastructure engineers were the ones who knew the APIs cold. The ones who'd memorised the quirks of the AWS provider, who knew which Kubernetes annotations did what, who could debug a Terraform state file at 2am. That knowledge doesn't become worthless. But it stops being the bottleneck. When agents can execute against any system through typed extensions, the hard part moves to the person expressing what needs to happen.
Most engineers are trained to think in terms of implementation: which resources, which configurations, which API calls. Thinking in terms of intent is a different muscle. What are my actual requirements? What are my real constraints? What does success look like?
Back to the sovereign cloud example. An engineer who thinks in implementation terms starts by asking "which Terraform provider do I need for Elastx?" An engineer who thinks in intent terms starts by asking "what are my data residency requirements, what workloads need to move, and what's my tolerance for disruption?" The first question leads to months of rewriting. The second leads to a migration plan.
Why this matters beyond sovereign cloud #
Sovereign cloud is the example, but the pattern is the same everywhere the execution cost has blocked a decision someone already made.
Migrating between cloud providers. Adopting new observability tooling. Consolidating from five deployment tools to one. Implementing compliance controls across a multi-region estate. In every case, someone decided what needed to happen months or years before the implementation finished, because the implementation meant rewriting automation against a different set of APIs.
We recently went through a smaller version of this ourselves. We decided we no longer wanted to be tightly coupled to GitHub. We'd already moved our issue tracking elsewhere, and we wanted more control over how source control and automation worked. So we replaced GitHub with Forgejo running on a DigitalOcean instance, then swapped GitHub Actions for a small compute cluster running Forgejo runners. All of it driven through swamp. Two years ago, that kind of migration would have turned into a quarter-long infrastructure project. This took a couple of days, including the infrastructure work and testing. The hard part wasn't the mechanics. It was being clear about what we actually needed the system to do.
That's what happens when the execution cost drops. Decisions that used to be too expensive to act on become decisions you can just make.
Architecture is intent now #
We spent two decades getting good at describing implementation. HCL, YAML, Kubernetes manifests, Helm templates. Languages for saying exactly how to build something against a specific set of APIs.
The work that matters now is describing what needs to exist and why, with enough precision that a deterministic system can deliver it. The constraints, the requirements, the failure modes, the sequencing.
There's a practical consequence too: precise intent is cheaper. A vague direction sends an agent exploring, burning tokens on dead ends and retries. Precise intent sends it executing. The difference in token cost between "move us off AWS" and a detailed migration intent isn't marginal. It's an order of magnitude. Getting good at expressing intent doesn't just produce better outcomes. It produces them for less.
The sovereign cloud movement will test every organisation's ability to move. The ones with the right tooling and the clarity to express what they need will move in days. The ones still rewriting modules will be at it for quarters.