Most organisations do not choose lock-in. They arrive at it one convenient decision at a time: a managed database here, a proprietary identity service there, a data lake that only speaks one dialect. By the time the invoice, the outage, or the geopolitical headline forces a rethink, moving has become a project measured in years rather than weeks. That is the quiet power of vendor lock-in — it is rarely dramatic, but it steadily narrows your options until someone else effectively sets your budget, your architecture, and your risk exposure.
For European businesses and public bodies, this is no longer an abstract IT-governance concern. Roughly two-thirds of European enterprise data sits with three US providers — AWS held around 31 percent of the global cloud market in 2023, Microsoft Azure around 25 percent, and Google Cloud around 11 percent. Concentration on that scale turns a commercial dependency into a sovereignty question. This article explains why lock-in matters, what the law now gives you, and how to plan a realistic exit.
What lock-in actually costs you
Lock-in is best understood as a loss of leverage. When switching is expensive and slow, your provider knows it — and prices, terms, and roadmap priorities reflect that knowledge. The costs show up in several places at once. There are direct exit costs, most visibly egress fees: for ordinary data transfers, AWS charges around $0.09 per GB and Azure around $0.087 per GB, and providers typically charge several times more to retrieve data than to store it. That multiplier is not an accident; it is the mechanism that makes leaving expensive.
But the larger costs are structural. Proprietary APIs, managed services with no open equivalent, and data formats that resist export mean your engineers build for one platform and slowly lose the ability to build for any other. Every year of deeper integration raises the cost of the eventual move. Concentration risk compounds this: a single provider outage, price change, or account suspension can halt operations you no longer know how to run elsewhere. Lock-in, in short, converts a supplier relationship into a dependency you cannot easily price or exit.
The jurisdiction problem you cannot configure away
The most underestimated risk is legal, not technical. The US CLOUD Act of 2018 allows US authorities to compel American providers to hand over data they control — regardless of where that data physically sits. A data centre in Frankfurt does not change the provider's nationality, and it is the provider's nationality that determines reach. "EU regions" and "sovereign cloud" offerings address where servers are, not who ultimately controls them.
This collides directly with EU law. In the Schrems II ruling of 16 July 2020, the Court of Justice struck down the Privacy Shield precisely because US surveillance law fails to offer EU-equivalent protection. The EU-US Data Privacy Framework, adopted on 10 July 2023, restored a transfer basis for certified US firms — but many observers already anticipate a "Schrems III" challenge, and the framework can be revoked or invalidated with little warning. Building critical infrastructure on a legal basis that could change is itself a form of lock-in — one you cannot refactor your way out of.
What the EU Data Act changes in your favour
The regulatory ground has shifted decisively toward customers. The EU Data Act (Regulation (EU) 2023/2854) entered into force in January 2024 and its cloud-switching provisions apply from 12 September 2025. For the first time, the right to leave is written into law rather than left to the goodwill of your contract.
Providers must now remove the pre-commercial, commercial, technical, and contractual obstacles that trap customers. Contracts must permit switching to another provider or to your own on-premises infrastructure, with a maximum notice period of two months. Data and digital assets — not just raw data, but configurations, metadata, and models — must be provided in a structured, commonly used, interoperable format. And crucially, switching fees, including punitive egress charges, must be fully eliminated by 12 September 2027. Anticipating this, the major providers already dropped exit egress fees for full migrations in 2024. The practical takeaway: the leverage is moving to you, and contracts you sign now should be negotiated on that assumption.
Open standards are the real exit insurance
A legal right to your data is worth little if the data only makes sense inside one vendor's tooling. Portability is a property of your architecture, not a clause in a contract. The durable defence against lock-in is to build on open standards and portable formats from the outset: Kubernetes and OCI containers instead of proprietary orchestration, PostgreSQL instead of a vendor-only database, S3-compatible object storage, OpenDocument formats, and open protocols for identity and messaging.
European initiatives are converging on exactly this principle. Gaia-X is building a federation of interconnected providers based on open standards, explicitly to prevent power concentrating with any single player. The EUCS cybersecurity certification scheme, developed by ENISA under the Cybersecurity Act, aims to give buyers a common yardstick for cloud assurance. Wherever you can, prefer components with a documented open specification and more than one implementation — that is what keeps a future migration a configuration change rather than a rewrite.
A pragmatic, phased migration approach
A "big bang" exit is rarely wise and rarely necessary. Treat migration as a portfolio exercise. First, map your dependencies honestly: which workloads use proprietary managed services with no open equivalent, and which are already portable? Second, classify by exit difficulty and by risk — data governed by GDPR or NIS2 obligations, or subject to CLOUD Act exposure, earns priority regardless of technical ease.
Then move in waves. Begin with the workloads that are both high-risk and low-effort to relocate — often object storage, backups, email, and collaboration tools where mature European alternatives already exist. Use these early wins to build muscle and prove the economics. Tackle deeply-integrated, stateful systems later, once your teams have re-learned portable patterns. Throughout, adopt an exit-by-design discipline: for every new system, write down how you would leave it before you commit. A migration you have rehearsed on paper is a migration you can actually execute.
Proof that it works: the public-sector example
Scepticism about migration usually rests on the belief that it is too disruptive to attempt. Schleswig-Holstein has been quietly disproving that. The German state has made LibreOffice the binding office standard, with close to 80 percent of workstations outside the tax administration already migrated. On 2 October 2025 it completed the move from Microsoft Exchange and Outlook to Open-Xchange and Thunderbird — a transition covering more than 40,000 mailboxes and over 100 million emails and calendar entries.
The state reports licence savings on the order of €15 million and is now working toward Linux desktops, an open directory service, and eventual use of openDesk, the sovereign workplace suite developed by Germany's ZenDiS. The lesson is not that everyone must run LibreOffice. It is that a large, complex, risk-averse organisation can execute a phased exit from an entrenched incumbent, absorb the friction, and come out with lower costs and greater control. What a public administration can do under scrutiny, a private business can do too.
Your practical checklist
Start with visibility. You cannot exit what you have not mapped, so inventory your provider dependencies and grade each by switching difficulty, data sensitivity, and legal exposure. Renegotiate contracts against the Data Act baseline — two-month notice, portable formats, no switching fees — and refuse terms weaker than what the law now guarantees.
Then reduce optionality loss going forward: favour open standards, keep at least one workload deliberately portable as a proof point, and evaluate European alternatives for the categories where they are already strong — email, storage, collaboration, and productivity. You do not need to abandon every US service tomorrow, and a well-run hyperscaler still has legitimate uses. The goal is not purity; it is leverage. An organisation that can credibly leave is an organisation that negotiates from strength, controls its own risk, and keeps its digital sovereignty in its own hands.
