No Lock-In by Construction
In the companion post we argued the real sovereignty test is whether you can leave. This is the engineer's answer to the obvious follow-up: how do you build a system so that leaving is a rehearsed operation instead of a hostage negotiation, including leaving us?
Part of the pillar series Sovereignty You Can Actually Operate.
Most anti-lock-in advice is a list of things to avoid. That's necessary but insufficient, because lock-in isn't a mistake you make once; it accumulates, quietly, every time you reach for a convenient proprietary service. The durable answer is architectural: build so that portability is a property of the system, not a project you'll get to later. Call it no lock-in by construction.
Three pillars hold it up (an open-source core, open standards and portable data, and a tested exit) plus one principle that ties them together: the customer should be able to leave even a sovereign provider, or the sovereignty is just a nicer cage.
Pillar 1: An open-source core you can actually inspect
A "sovereign but proprietary" black box has a problem: you're trusting a claim you can't verify. Open source changes the trust model from "believe us" to "check for yourself." That's not ideology; it's auditability. Europe's public sector has leaned into this hard: the European Commission's own Open Source Strategy commits that its software "will be open sourced," and the "Public Money? Public Code!" campaign, backed by hundreds of organizations, argues that publicly funded software should be public and inspectable for exactly this reason (FSFE).
And it works at serious scale. France's national Gendarmerie has run its own Linux desktop, GendBuntu, across more than 103,000 workstations (around 97% of the force) for well over a decade, cutting total cost of ownership by roughly 40% (OSOR / European Commission). That's not a pilot; it's two decades of evidence that an inspectable core is operable, durable, and cheaper.
Pillar 2: Open standards and portable data
Lock-in lives in formats and interfaces as much as in contracts. If your data only makes sense inside one vendor's system, you don't own it; you rent access to it. The countermeasure is to build on open standards at every layer where they exist:
| Layer | Open standard | Why it prevents lock-in |
|---|---|---|
| Documents | ODF (ISO/IEC 26300) | Germany's federal administration is mandating ODF so files outlive any one vendor |
| Packaging | OCI containers | Vendor-neutral; the same workload runs anywhere |
| Data export | "Structured, commonly used, machine-readable" | The EU Data Act's legal floor: design to it now |
| Interfaces | Open, documented APIs | The Data Act requires them for portability (Art. 23–30) |
The regulatory floor is rising to meet good practice here: the Data Act mandates machine-readable export and "functional equivalence" on switching, and from 12 January 2027 removes egress fees entirely (Data Act Art. 29). If your export already targets open formats, you're ahead of the deadline instead of scrambling for it.
Pillar 3: A tested exit, treated like disaster recovery
Here's the discipline most teams skip: an exit plan that has never been executed is fiction. Supervisors have caught up to this: the ECB and EBA now expect exit strategies to be in place before go-live and tested periodically, with a maintained list of qualified alternatives, and DORA makes tested exit a hard requirement for critical functions (DORA Art. 28). Treat exit like DR: rehearse the migration, measure how long it takes and what it costs, and fix what breaks before the day you need it. As one practitioner put it plainly, "without an exit option, 'sovereignty' is just a slogan" (Korte, 2026).
The cautionary tale, and the principle
Why all this rigour? Because the alternative is on the record. When a widely-used virtualization platform was acquired, its new owner pushed through licensing changes that European providers said raised prices 800% to 1,500%, ended perpetual licenses, and forced multi-year commitments (CISPE/ECCO, 2025). Every one of those customers had "chosen" that software years earlier. Closed, acquirable software means your future terms are set by whoever owns the vendor next, not by you.
Which leads to the principle that governs everything above: you should be able to leave even your sovereign provider. Sovereignty that depends on trusting one European vendor forever is just dependency wearing a better flag. Real portability means the option to walk is always live, and that's a design constraint, not a marketing line.
How we build it into the Soveryne Cloud Foundation
We hold ourselves to that principle, which is uncomfortable for a vendor and exactly the point. The Soveryne Cloud Foundation is built on an open-source core you can inspect, with your data portable and your keys in your jurisdiction, so leaving never means stranding either. And for the strictest deployments, the Soveryne tier includes knowledge transfer to your own team and on-premises options: we deliberately hand over the operational capability to run it, so sovereignty with us never becomes dependence on us. Paired with Command, the tested exit stops being a document you file and becomes a control you keep current.
The goal is not to make leaving painless because we expect you to. It's to earn the relationship by never trapping it.
FAQ
How do you avoid vendor lock-in by design? Build on an open-source core, use open standards and formats (ODF, OCI, open APIs), keep data machine-readable and keys under your control, and rehearse a tested exit. Portability becomes a property of the system rather than a future project.
Why does open source matter for sovereignty? Because it turns "trust us" into "verify it." An inspectable core can be audited, modified, and operated by your own team: the difference between sovereignty and a nicer black box.
Isn't a European sovereign provider enough? Only if you can also leave it. Sovereignty that depends on trusting one vendor indefinitely is still dependency. The design goal is that you can walk away from any provider, sovereign ones included.
What does the EU Data Act change for portability? It mandates machine-readable export and functional equivalence on switching, caps transition periods, and from 12 January 2027 bans egress and switching fees, making portability the legal default, not a premium.
Build so leaving is a rehearsal, not a rescue. See the open-core, portable, EU-sovereign foundation, the one we'd want you to be able to leave: explore the Soveryne Cloud Foundation, or read the companion piece on why exit is the real test.
Sources
- FSFE, Public Money? Public Code!: https://publiccode.eu/en/openletter/
- European Commission, Open Source Software Strategy: https://commission.europa.eu/about/departments-and-executive-agencies/digital-services/open-source-software-strategy_en
- OSOR / European Commission, French Gendarmerie open source (GendBuntu): https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/french-gendarmerie-open-sou
- EU Data Act, Article 29 (switching/egress): https://www.eu-data-act.com/Data_Act_Article_29.html
- DORA, Article 28 (exit strategies): https://www.digital-operational-resilience-act.com/Article_28.html
- CISPE / ECCO on Broadcom-VMware licensing: https://www.theregister.com/2025/10/28/cispe_ecco_broadcom/
- Korte, "Exit strategy: a key to digital sovereignty" (2026): https://www.korte.co/2026/02/12/exit-strategy-a-key-to-digital-sovereignty/
Eight posts in, from the dependence map to the region lock, here's the synthesis: the minimum architecture that honestly earns the word "sovereign." Not a product pitch: a blueprint you can hold your own stack against.
Read the next part
Every sovereignty conversation eventually reaches the same question, and it's the one that actually matters: if you had to leave your provider next quarter (because of a price hike, a breach, a legal order, or a geopolitical shock), could you? And could you prove it?
Read the companion piece
