A few weeks ago, someone said to me at a conference dinner, almost apologetically, “We’d love to move away from AWS, but it’s just impossible.”
I’ve heard this phrase often enough, in one form or another, to recognize what lies behind it. Frustration. Uncertainty. That nagging feeling that the major cloud providers are now so deeply intertwined with everything that there’s no escaping them. And every time, I recognize that feeling: that mix of inevitability, a slight pang of guilt, and the suspicion that you’re being taken advantage of.
Sometimes this feeling is justified. Often enough, however, it has also been carefully cultivated.
After more than thirty years in this industry—first as a sysadmin, then as a developer, and now as a CEO—I’m pretty convinced that the perceived impossibility of leaving the hyperscalers is, at least in part, a story they’ve learned to tell very well. The technical reality is usually much more boring.
And boring is exactly what you want.
So my argument is simple: A sovereign cloud doesn’t have to clone 200 hyperscaler services to be a real alternative. And if you think you could never leave the public cloud, you’re probably wrong
The Dependence We Like to Downplay
Most European companies say they want to reduce their dependence on U.S. providers. And yet that dependence keeps growing—the European market share in the cloud business has been shrinking for years instead of growing. We find ourselves in this strange situation where almost everyone says they want change, while doing exactly the opposite.
Part of that is true. Hyperscalers are good at what they do, and migrating is a lot of work. But another part is more uncomfortable: The hyperscalers have spent fifteen years building an ecosystem in which leaving not only feels expensive, but also somehow irresponsible. As if no serious company could survive without the entire catalog.
The current wave of “sovereign cloud” announcements from AWS, Microsoft, and Google builds precisely on this sentiment. Localized data centers. Staff based in the EU. Regions operated by partners. Sometimes useful. But the parent company remains subject to the U.S. CLOUD Act, which allows U.S. authorities to compel access to data held by U.S. companies—regardless of where the servers are physically located.
If you want an example that sums it up: In June 2025, the Director of Public and Legal Affairs for Microsoft France was asked by the French Senate whether he could guarantee that the data of French citizens would never be shared with U.S. authorities. He couldn’t. He said that it hadn’t happened so far.
That’s not sovereignty. That’s hope with an SLA attached.
There’s now a term for this: “sovereignty washing.” And yes, that annoys me. Calling something “sovereign” when the parent company is just one court order away from a different outcome isn’t enough. At best, it’s a partial risk mitigation. At worst, marketing is doing the work that architecture was supposed to do.
It’s worth being precise about what “sovereign” actually means, because the word has been stretched so far that it covers almost everything. For me, it’s not just one question, but a small stack of them: Who owns the company providing the service? Under whose jurisdiction does it operate? Who operates the control plane? Who holds the encryption keys? And can you auditably account for all of this—and actually walk away with your data within a known timeframe? A truly sovereign offering should have clear answers to all of these questions. Most badges currently on the market answer one or two of these questions and remain silent on the rest.
A useful counterexample is OpenStack. Managed by the OpenInfra Foundation as a vendor-neutral project—with open source code and no single company controlling the roadmap—it addresses issues of ownership, legal framework, and exit strategies structurally rather than contractually: you can run it yourself, you can switch providers, and the artifact you depend on won’t disappear if a vendor changes its mind. That is the benchmark by which “sovereignty” should be measured, in my opinion: not a label that a provider assigns to itself, but an architecture and a governance model that would still hold up even if the provider were to disappear tomorrow.
And that is precisely why open source is not an aesthetic choice in this debate, but a prerequisite. The reason OpenStack can provide these clear answers is that the source code is open, the license is permissive enough to actually use it, and the governance is structured in such a way that no single party can pull the rug from under you. Take away even one of these, and “sovereignty” collapses once again into nothing more than a marketing claim. You can read the code, fork it, run it on your own hardware, and verify what it does—none of this is negotiable when the alternative is to trust a vendor’s word about where your data is going. Closed-source sovereignty is a contradiction in itself: You’re always just one acquisition, one license change, or one government access request away from discovering that the answers you were given came with strings attached.
The Myth of the 200 Services
This is where the conversation usually gets stuck. People say, “That’s all well and good, but European providers don’t offer the services we need.”
And if you judge a cloud provider by the size of its catalog, they’re right. AWS alone has well over 200 services. But here’s the question I usually put aside:
How many of these services do you actually use?
In most setups I see, the honest answer is somewhere between five and fifteen. Compute. Object storage. A managed database. A container platform. A bit of IAM. Maybe a queue. Maybe a CDN. The rest is a wonderfully marketed buffet that nobody eats—but everyone pays for: with cognitive overhead, with lock-in, and with the operational costs of piecing it all together.
Dan McKinley summed this up years ago in an essay that every infrastructure professional should read once a year: “Choose Boring Technology.” His core idea is the “Innovation Token.” Every team has a small innovation budget that it can spend on its tech stack. Spend it where it sets your business apart. Don’t spend it on a sixth message bus.
Sovereign providers keep you—sometimes out of necessity—closer to the boring basics. PostgreSQL. S3-compatible object storage. Kubernetes on OpenStack. Plain old cron. None of it is glamorous. Most of it has been running in production since half of the AWS catalog didn’t even exist. The error patterns are well-known. The documentation doesn’t change every five minutes. A competent SRE starting next month will recognize what they’re dealing with—without having to go through three rounds of vendor certification.
This last point is more important than we care to admit. We talk a lot about cost, lock-in, and sovereignty. We talk less about the engineering time that’s wasted on just keeping up with hyperscaler-specific tooling that changes every quarter. This time sink is real. It shows up during onboarding, in incidents, in architecture meetings, and in the quiet fear that no one fully understands the system anymore.
Where Hyperscalers Belong
Before I go too far in the other direction: For some workloads, hyperscalers are the right solution, and to claim otherwise would just be another form of marketing. If you really need a global edge presence across twenty regions, if your business depends on the most sophisticated managed AI or analytics services on the planet, if you have a platform team that’s large enough to handle the operational complexity, or if time-to-market is more important than portability for the next eighteen months—then go with the hyperscalers, and don’t apologize for it.
The mistake isn’t using AWS or Azure, but using them by default for workloads that don’t need them. A startup that needs DynamoDB Global Tables and Bedrock today shouldn’t run its own OpenStack cluster just to prove a point. A medium-sized company that runs a few dozen services that interact with an SQL database and an object store probably shouldn’t pay for complexity it doesn’t even use.
Most of the workloads I see fall into the second category, not the first. That’s exactly where it’s worth having a conversation.
“But we’re already in too deep to get out.”
Three objections come up almost every time. The same three, usually in the same order.
“We’ve built so much on hyperscaler-specific services that migrating would mean rewriting half the stack.”
Sometimes that’s true. The honest answer is: Yes, that’s the price of the decisions that were made. But in practice, the rewrite is usually smaller than people fear. If your workload runs in containers, communicates with an SQL database, and stores blobs via an S3-compatible API, you’re already largely portable. The real pain comes when teams have heavily relied on proprietary serverless solutions or vendor-specific identity glue. No magic trick can make that go away. My advice is boring: Stop digging the hole any deeper. Make new systems portable by default and migrate the rest at natural points in time—a redesign, a contract renewal, a platform refresh.
“Independent providers cannot compete with the hyperscalers’ service catalog.”
That’s right. They also can’t keep up with the surprise bill at the end of the quarter, the egress fees that nobody really planned for, or the operational complexity hidden in that bill. Some hyperscaler setups are really affordable, especially with serious commitments and reserved capacity. Many others aren’t, and the costs only become apparent when you try to leave.
“Migration is too risky and takes too long.”
This is the one I disagree with the most. A client came to us, firmly convinced that their AWS migration would be an eighteen-month project requiring three engineers. We sat down and looked at the actual deployment—not the architectural diagram, but the real thing. About forty containerized services on EKS, a primary PostgreSQL instance on RDS, a few terabytes in S3, and the usual tangled mess of CloudWatch dashboards and IAM policies tacked on around it all.
Most of it—the containers, the database, the object storage—was migrated in about six weeks. The PostgreSQL cutover required a scheduled maintenance window of about forty minutes; everything else ran in parallel until we switched over the traffic. The long tail came afterward: a handful of Lambda functions that had to be rewritten as scheduled jobs, some Cognito-style identity glue, and CloudWatch alarms that had to be redefined in Prometheus and Alertmanager. Annoying, but manageable—and not the part that determines whether the migration is feasible.
The migration of the headlines—the part that was supposedly impossible—wasn’t impossible at all.
The interesting question isn’t whether it’s possible to move out, but why so many companies don’t even try to do so in the first place.
How this works in practice
Just a quick aside, because I should make this clear: NETWAYS —the group of companies I lead—operates its own OpenStack-based cloud platform called NETWAYS Web Services, which Sebastian and his team have developed into a highly competitive solution. So, yes, I do have a stake in this. You can read that as commercial bias. Fair enough. You could also see it as the perspective of someone who has experienced these migrations in real customer environments, not just on slides. That’s fair, too. I’d rather acknowledge my bias than pretend I don’t have one.
So how do you actually migrate? The boring answer is the right one.
Take stock of your real dependencies, not your imagined ones. Most teams find that a large portion of their workload is already portable and that the non-portable portion is concentrated in a few vendor-specific services they adopted back then simply because it was convenient at the time.
Choose boring abstractions. Containers. Kubernetes. PostgreSQL. S3-compatible storage. OpenStack underneath. These are the building blocks on which everything runs, from CERN’s research workloads to telecommunications networks.
Start with the simple things first. Stateless services and batch workloads are usually inexpensive to migrate; they immediately reduce your hyperscaler footprint, and the savings help fund the more difficult parts.
And please, resist the urge to replicate the hyperscaler catalog on your own cloud. That’s where the madness lies. Most of these services exist to pull you deeper into the ecosystem, not to make your life easier. You probably didn’t need most of them from the start.
You’re not trapped
The feeling that it’s impossible to break away from the hyperscalers is real. I don’t want to dismiss it. But it’s not primarily rooted in the actual technologies used. It has been cultivated.
Hyperscalers aren’t evil. No one has to rip everything out tomorrow. But the sense of hopelessness you feel is often manufactured. The unassuming, reliable open-source alternative is closer than you think.
You owe no loyalty to AWS, Microsoft, or Google. You owe your users, your team, and your business a tech stack that you can think through, that you can walk away from if you have to, and that lets you sleep soundly at night.
That’s basically it. Mostly unglamorous engineering and a willingness to stop believing what marketing tells us.
After a good thirty years in this industry, I can tell you: It’s harder than it sounds. But much easier than the salespeople would have you believe.
0 Comments