Sovereign Cloud Is Portfolio Triage, Not a Vendor Swap

The loudest mistake I see in “sovereign cloud” conversations is treating it like procurement. Swap AWS for a European provider, update the slide deck, and declare victory.

Operators know better. Real sovereignty is an operating property. It lives in how identity is controlled, where keys are held, how logs are retained, how data moves, and whether you can exit under pressure. If those mechanisms are weak, a vendor logo change does nothing. It just adds migration cost and a new failure mode.

This is why the recent move where a major European aircraft manufacturer plans to migrate 70 critical systems from AWS to the French cloud provider Scaleway matters. Not because “Europe good, US bad”. It matters because it forces the only question that counts: what, exactly, makes those 70 systems “under European control”, and how will that be audited in two years when everyone is tired of the program?

When I ran an international business unit in smart-building and connected controls, and later when I owned operations across engineering, production, and service in electrification and energy storage, I learned a simple rule. If a control cannot be tested, it will not survive contact with reality. Cloud sovereignty is the same.

The only useful definition: sovereignty is auditable control

I do not care what your provider calls itself. I care about whether you can prove, on demand, who can access what, who can decrypt what, what data left the boundary, and how fast you can move a workload away.

That proof comes from a control plane. Not “a platform”, not “a landing zone”, not “best practices”. A concrete set of mechanisms that constrain behavior every day.

If you want one mental model, borrow it from industrial operations. A factory is not “safe” because the machines are European. It is safe because lockout-tagout, change control, maintenance logs, and safety drills exist and are enforced. Your sovereign cloud posture needs the same discipline.

Step one is triage: classify the portfolio before you touch anything

Vendor swaps fail because teams start with the migration plan, not with workload truth. Start by classifying the portfolio into four buckets. Then migrate only what the classification demands.

1. Anchor workloads (must move). These are systems where legal exposure, export controls, or customer contracts create hard constraints. Often: identity directories, key management, security telemetry, and a subset of data platforms. Moving these is expensive, but leaving them where they are makes sovereignty a story.
2. Coupled workloads (move later, after decoupling). They are “critical” mostly because of integrations. ERP adjacent services, integration middleware, shared databases, message brokers. If you lift-and-shift them, you import fragility into the new environment.
3. Commodity workloads (stay, but constrain). Collaboration tools, developer tooling, generic analytics. Here, sovereignty is achieved by policy and data minimization, not by relocation. Make sure you are not storing regulated data where it does not belong, and stop there.
4. Sunset candidates (do not migrate). The fastest sovereign win is retiring systems you should have killed three years ago. Migration is a perfect excuse to delete.

This triage is not a technical workshop. It is a leadership decision. It forces tradeoffs: cost, delivery risk, and what “critical” actually means.

The control-plane patterns that make sovereignty real

Once you have triage, you need patterns that create evidence. These are the ones I would insist on, whether I was running a manufacturing-heavy business or building a SaaS platform like IBHQ.

1) Identity is the root of control

Sovereignty collapses if your identity plane is effectively controlled elsewhere. The pattern is simple:

• One authoritative identity for workforce and machine identities. No local snowflakes per cloud.
• Privileged access is isolated. Separate admin identities, short-lived elevation, and explicit approval paths.
• Break-glass accounts exist and are tested, not just documented.

If you cannot answer “who can assume admin in the sovereign environment, and what external dependency grants that permission?”, you do not have sovereignty. You have hosting.

2) Keys are not a feature, they are custody

Every vendor claims encryption. The operator question is custody: who can compel access, and where are the keys controlled?

• Centralize key management with clear ownership. Do not let each product team invent its own crypto story.
• Separate key domains by data class. Regulated datasets should not share the same blast radius as everything else.
• Rotate and revoke as a drill. If you cannot rotate keys without downtime, your posture is brittle.

This is where “digital sovereignty” stops being political and becomes operational.

3) Logging is the audit trail, not an afterthought

In industrial quality work, if an event is not logged, it did not happen. In cloud, if access is not logged, it cannot be governed.

• Centralize logs across clouds and on-prem, including identity events, admin actions, and data access.
• Make logs tamper-evident. Write-once storage or equivalent controls, with retention aligned to obligations.
• Define an “audit query pack”: a handful of queries you can run in minutes to answer regulators, customers, and incident responders.

This aligns tightly with how I think about applied AI too. AI can help you summarize and triage, but the truth layer is the event trail. If you want a related lens, my piece AI leadership is workflow leadership applies here. Sovereignty is also a chain of handoffs, not a technology choice.

4) Data gravity decides what can move

Most sovereignty programs fail on data gravity, not compute. Data pulls applications, integrations, and workflows with it.

• Classify data by residency and sensitivity, then map where it actually lives today.
• Design “data egress choke points”. Not to block business, but to make movement explicit and measurable.
• Push sovereignty to the data product. A sovereign data platform with strict access boundaries can support many applications without migrating everything.

In manufacturing tech, we learned that connected sensors do not buy you uptime. Operating discipline does. Same here. If your data contracts are sloppy, no cloud choice will save you. This is why I keep coming back to the idea that failure often starts with the data contract.

5) Exit tests are the only credible sovereignty KPI

Every provider promises portability. Your job is to turn that promise into a routine.

• Define exit targets per workload class: RTO, RPO, and acceptable degraded modes.
• Automate exports of data, configurations, and infrastructure definitions. If it is manual, it will not happen under stress.
• Run exit tests like fire drills. Quarterly for anchors, semiannually for coupled workloads, and at least once for everything else.

This is the part most leaders avoid because it feels like “wasted work”. It is not wasted. It is insurance, and it is also leverage in every vendor negotiation.

A lived lesson: migrations punish ambiguity, not complexity

When I rebuilt and scaled an R&D organization spanning embedded software, cloud, electronics, mechanics, and QA, I learned that cross-domain programs break when responsibilities are fuzzy. People do what they can measure, and they ignore what they cannot.

Sovereign cloud programs are cross-domain by nature. Security wants controls. Legal wants defensibility. Engineering wants uptime. Finance wants predictability. If you do not translate “sovereignty” into a measurable control plane, every function will interpret it differently, and delivery becomes a debate instead of execution.

In my own ventures, especially when building IBHQ and Shopeno, I default to simple operator rules: standardize identity, centralize logging, keep keys under clear custody, minimize regulated data sprawl, and test exits. Those rules reduce dependency risk without slowing product work.

My opinion: sovereign cloud is earned through operating discipline

Sovereignty is not the provider. It is the proof.

If you want this to work this quarter, do three things. First, triage the portfolio into move, constrain, decouple, and sunset. Second, implement the control-plane minimum: identity, keys, logs, data boundaries, and exit tests. Third, insist on evidence. If a control is not testable, it is not real.

That is how you avoid theater, and that is how you make “under European control” mean something when the next crisis hits.