In our previous posts, we discussed sovereignty as a risk, the trade-offs that come with it, and the reality of Europe building its own hyperscale ecosystem. The conclusion we derived from that is not comfortable, but it is essential:
There is no architectural pattern, provider choice, or regulatory construct that fully removes sovereignty risk.
Not in a global, interconnected digital economy.
Every solution, local, European, or global, operates within overlapping legal frameworks, depends on international supply chains, and is exposed to geopolitical dynamics and requires extreme strong security measures for globally created threats.
That changes the question.
It is not: “How do we avoid sovereignty risk?”It is:
“How do we shape it into something acceptable?”
That question doesn’t have a single answer. If you look at the current discourse, it sounds deceptively simple: build a European hyperscaler, move to local providers, go fully open source. Pick your path, regain sovereignty.
But as we’ve already seen, that framing ignores reality. As every choice comes with consequences, every model introduces trade-offs and in effect, there is no “sovereign option” without cost, dependency, or new forms of exposure. Which means the decision cannot be made in abstract terms (it’s not binary).
Each organization (and in many cases, each workload) needs to make an explicit call:
- What risks do we actually face?
- How likely are they?
- What happens if they materialize?
- What are we willing to trade to mitigate?
- And how does that compare to the compromise we’re making elsewhere?
Let’s frame this in a real-world example.
M365/GW – the core of most companies
A practical way to look at this is something most organizations rely on today: Microsoft 365 or Google Workspace.
Both deliver a broad set of integrated services, identity protection, built-in security, and continuous updates, creating a level of defense-in-depth that is difficult to replicate in fragmented environments. But we cannot ignore the sovereignty risks to our data and service availability. Legal access frameworks apply, often across multiple jurisdictions. Sanctions, while rare, can impact service availability. So what are the options?
One approach is to move away entirely, towards local providers, open-source, or a combination of smaller platforms. But as we’ve seen that comes at a cost.
There is no single alternative that matches the functional and security scope of Google Workplace or M365. In practice, you move to multiple providers, different platforms with the requirement to rebuild integrations, and often give up advanced capabilities such as identity protection, data classification systems, threat detection, and operational security.
All of that… to primarily shift a specific class of risk.
And let’s be honest for some organizations, that risk is non-negotiable. In sectors like defense, public sector, or critical infrastructure, even a low-probability event can be unacceptable: Not because it’s likely, but because the impact is intolerable. In those cases, the decision is not about optimizing risk, but enforcing absolute constraints. However, that (non-negotiable) choice comes with consequences: higher cost, reduced capability, increased complexity.
Not because it’s efficient, but because their risk tolerance demands it.
And that’s a critical distinction. But one you can only make if you fully understand what you’re giving up. Too often, organizations don’t, they react to the narrative, not the trade-offs.
There is another path.
Take sanctions. High impact, extremely low probability. Instead of redesigning your entire environment, you prepare for it. Maintain independent backups. Define an exit strategy. Set clear triggers for when to act. If nothing happens, you keep the benefits, if something changes, you move. This doesn’t eliminate the sovereignty risk but it gives you awareness, optionality, and control, without paying the full price upfront.
When flying, we accept a certain risk. We don’t ignore it, but because we trust the systems, the engineering, and the layers of control that make those risks extremely unlikely. We could just accept it and fly. The more embedded we are in that system, the harder it becomes to walk away, but we accept that trade-off because of the scale, efficiency, and capability it gives us (vendor/cloud lock-in). Or we take a different route and build our own plane with more control, more visibility but we fly shorter distances, with less capability, and we take on much more responsibility ourselves. Or we do something in between: We bring a parachute. We don’t build a new plane ourselves. We prepare for the edge case.
Resiliency
I’m not going to address service resiliency. That’s well covered by every cloud provider’s marketing and SLA discussions. This is about cloud resiliency:
How do you avoid becoming trapped in an ever-expanding ecosystem, when vendor lock-in is often seen as the enemy of resiliency?
The more you depend on a single provider’s proprietary capabilities, the harder it becomes to move, adapt, or recover if something changes and in theory, the answer is simple: Use open, standards-based technologies, virtual machines, containers, databases, etc. By deliberately choosing a common denominator (which is platform independent), you gain portability. Your workloads can run across different environments, providers, or even on-premises, not tightly bound to a platform, a vendor, or even a specific hardware stack.
And this fully aligns with sovereignty thinking: Portability gives you options, you can host wherever and, in theory improve resiliency. So, problem solved?
Not quite.
Here we go again… That portability comes at a cost. Moving away from hyperscale-native capabilities means stepping back from continuous innovation, especially in areas like security, large-scale data processing, and AI. It also shifts responsibility back to the organization: integration, operations, and maintaining a consistent security posture across fragmented environments.
So while open standards increase portability, they often reduce capability, increase complexity, and shift operational burden. And just like with sovereignty, the answer is not binary.
At the same time, hyperscalers are adapting. They are introducing private cloud models, hybrid patterns, and more portable workload designs. Not as a favor, but because the market demands it. Customers want the benefits of scale and innovation but without feeling locked in, but let’s be honest here: Most (if not all) do not represent a “private cloud”. Perhaps in the way they are managed and deployed (via API’s), but they completely lack any of the hyperscale cloud benefits including most of the “lock-in” advanced services. You are responsible for the security, operations, hardware procurement and all the other downsides that apply to local hosting and sovereign hosters. In my opinion they are easy to deploy private hosting solutions, not clouds.
In practice, this leads to different patterns depending on the layer.
At the IaaS and PaaS level, many organizations design with portability in mind. Open standards provide reassurance: workloads can move if required. Yet in practice, once native capabilities are used (managed databases, analytics platforms, AI services, Governance) the equation changes. The benefits quickly outweigh the theoretical portability as innovation accelerates, operational overhead drops, and the platform starts to deliver outsized value. And that’s where dependency deepens. Not because organizations set out to be locked in, but because the value becomes tangible and difficult to give up. What starts as a design choice for flexibility often evolves into a deliberate acceptance of dependency.
At the SaaS layer, portability becomes even harder. These platforms are deeply integrated, continuously evolving ecosystems. The value is not just in the functionality, but in the cohesion of the services themselves. Replacing that is rarely a like-for-like exercise.
Which brings us back to the core tension.
Lock-in drives value: integration, innovation speed, ease of use.
Portability drives flexibility: choice, independence, and optionality.
Finding the right balance is not a one-time decision, but something that needs to be evaluated per application and in the context of the business itself. The acceptable level of dependency is not just a technical choice, it is shaped by industry dynamics, competitive pressure, and the pace at which an organization needs to innovate.
Choosing portability may increase flexibility, but it can also slow down innovation, reduce access to advanced capabilities, and ultimately impact time-to-market. In fast-moving industries, that trade-off can translate into lost opportunity. At the same time, maximizing platform-native value increases dependency, with associated sovereignty and lock-in considerations.
The decision, therefore, is not about avoiding one or the other, but about deliberately positioning each workload along that spectrum, balancing risk, capability, and competitive reality.
Choices
So, I’m not going to tell you what your choice should be – I don’t know your risk apetite, your business landscape or what a local hoster will promise next. And frankly, it’s not helpful when sovereignty narratives turn into over-simplified prescriptions, “just move,” “just go local,” “just go open-source.” Those recommendations might reduce a specific risk, but they can introduce significant business impact elsewhere.
Sovereignty and resiliency need to be made visible, understood, and aligned with business priorities and that can mean different things:
- accepting the risk flat out
- building exit strategies (“the parachute”)
- deliberately lowering the tech stack to increase portability
- or fully moving to non-hyperscale environments where required
All are valid but only in the right context and they are surely not free of consequences.
So we need to take a more disciplined approach that is not driven by narrative, ideology or marketing, but by explicit trade-offs.
For every workload, every platform decision, the question should be:
- What value to we derive out of this?
- What risks are we exposed to?
- What is the probability vs. the impact?
- What are we dependent on?
- What happens if that dependency breaks?
- And what are we willing to trade to change that?
Because the reality is that you are always trading:
- control vs. capability
- portability vs. innovation
- isolation vs. efficiency
And that is ultimately the difference between organizations that manage sovereignty and resiliency.
Conclusion
Sovereignty and resiliency ultimately point to the same reality: you operate within dependencies you do not fully control. Legal frameworks, platforms, and supply chains don’t disappear with architecture choices, they shift. The question is no longer how to avoid these risks, but how to make them acceptable within your business context.
There is no “right” answer. Only trade-offs between control, capability, portability, and cost. Some organizations will prioritize flexibility, others innovation or absolute constraints, but all are making decisions that shape their exposure.
What sets strong organizations apart is not the path they choose, but how consciously they make it. They understand what they depend on, what happens if it breaks, and what they are willing to trade to change that.
The next challenge is how to actually have these conversations, across architecture, risk, and business leadership, without falling back into narratives or oversimplifications.
Intro: Digital Sovereignty
Chapter 1. Sovereign Risks
Chapter 2. Hyperscale advantages
Chapter 3. Sovereign Europe