Lock-In: A Room Without Doors

You Don't Notice the Walls Going Up

Nobody plans to get locked in. It happens gradually, one reasonable decision at a time. You pick a managed database because it saves operational effort. You adopt a proprietary queuing service because the integration is seamless. You sign a three-year reserved instance commitment because the discount is significant. You send your engineers to vendor certification courses because the training is subsidised.

Each decision makes perfect sense in isolation. Together, they build a structure around you. By the time you realise you're enclosed, moving out is a project that nobody wants to fund.

Cloud lock-in is often discussed as a single phenomenon, but it's actually four distinct forces. They reinforce each other, and understanding them separately is essential to managing them.

Wall One: Technical Lock-In

Technical lock-in is the most visible form. It happens when your systems depend on proprietary services that have no equivalent elsewhere. AWS Lambda, DynamoDB, Azure Cosmos DB, Google BigQuery. Each is a capable service. Each is available from exactly one provider.

The mechanism is straightforward. You build your application around a proprietary API. Your code calls that API thousands of times. Your architecture assumes the service's specific behaviour, its latency characteristics, its consistency model, its scaling patterns. Replacing it means rewriting, not just reconfiguring.

DynamoDB is a good example. It's a powerful NoSQL database, but its data model, query patterns, and capacity management are unlike anything else. Organisations that build heavily on DynamoDB report that migration requires not just moving data but redesigning how their applications think about storage. ScyllaDB, which offers a DynamoDB-compatible API specifically to ease migrations, describes the process as one of the most common pain points driving companies to seek alternatives.

The counterpoint is Kubernetes. Because it's governed by the Cloud Native Computing Foundation and implemented by dozens of providers, a deployment manifest that works on Scaleway Kapsule works on OVHcloud, Hetzner, or AWS EKS. The same is true for PostgreSQL, Prometheus, and other foundation-governed projects. When the interface is a genuine standard with multiple implementations, technical lock-in largely disappears.

The practical test is simple: could you run this component on a different provider without rewriting your application? If the answer is no, you've accepted technical lock-in. That might be a reasonable tradeoff, but it should be a conscious one.

Wall Two: Data Lock-In

Data lock-in is subtler than technical lock-in, and often more expensive to resolve. Your data is in a provider's region, stored in their format, integrated with their other services. Getting it out is technically possible but practically painful.

The economics tell the story. AWS charges around €0.09 per gigabyte for data leaving their network. That sounds modest until you calculate what it means for a production database. Moving 10 terabytes of data costs roughly €900 in egress fees alone, before you account for the engineering time to validate the migration, maintain consistency during the transition, and verify nothing was lost.

But egress fees are only the surface. The deeper problem is data gravity. Once your data lives in a provider's ecosystem, other services cluster around it. Your analytics pipeline reads from that database. Your machine learning models train on that data. Your backup systems, your audit logs, your compliance reports all reference it. Moving the data means moving or rebuilding everything that touches it.

37signals learned this firsthand. When David Heinemeier Hansson decided to leave AWS in 2023, the company was spending $3.2 million per year on cloud infrastructure. The migration to owned hardware ultimately saved them over $1.5 million annually. But the migration itself required months of careful work to extract data and rebuild the services that depended on AWS-specific storage and networking.

Europe's regulators have noticed. The EU Data Act, which entered into application in September 2025, requires cloud providers to offer open interfaces and standard formats for data export. Starting January 2027, providers won't be allowed to charge switching fees at all. This is a recognition that data lock-in is a market failure that regulation needs to address.

Wall Three: Contractual Lock-In

Contractual lock-in works through commitments, discounts, and penalties. It's the least technical form of lock-in, but often the hardest to escape because it involves legal obligations rather than engineering challenges.

The pattern is familiar. A cloud provider offers a 30 to 50 percent discount if you commit to one or three years of usage. The finance team loves the predictability. The procurement team appreciates the savings. Everyone signs. Now you're committed, and your negotiating position at renewal is weaker because migration during the contract term means paying for capacity you're not using.

Broadcom's acquisition of VMware in 2023 showed how contractual lock-in can turn painful overnight. After the acquisition, Broadcom restructured VMware's licensing from perpetual licenses to mandatory subscriptions, bundled products customers didn't need, and enforced minimum 72-core requirements. The European Cloud Consortium reported price increases between 800 and 1,500 percent. Customers locked into VMware's ecosystem had limited options: pay the increase, or fund a migration to alternatives like Proxmox or Kubernetes while still paying VMware during the transition.

Less dramatic but equally effective are the small contractual details. Termination fees. Data retention clauses that make it unclear who owns derivative data. Support tiers that bundle infrastructure management with the compute contract, so leaving the platform means losing operational support simultaneously.

The antidote is shorter commitments and explicit exit terms. Every contract should answer: what happens when we want to leave? What format will our data be in? What are the costs? How long will the transition take? If the contract doesn't address these questions clearly, the omission is itself a form of lock-in.

Wall Four: Skills Lock-In

Skills lock-in is the least discussed form, but it's often the decisive one. When your team's expertise is entirely in one provider's ecosystem, switching providers means retraining everyone, and retraining is slow, expensive, and disruptive.

Cloud providers understand this well. AWS has over a dozen certification programmes. Azure and Google Cloud have similar tracks. The certifications are genuinely valuable for working within those ecosystems. They're also specific to those ecosystems. An AWS Solutions Architect certification teaches you to think in AWS terms: regions, availability zones, VPCs, security groups, IAM policies. The concepts transfer partially, but the muscle memory, the tooling familiarity, and the troubleshooting instincts are vendor-specific.

The compounding effect is significant. Teams that spend years building on one platform develop institutional knowledge that's hard to quantify and impossible to export. They know the quirks: which service has unexpected rate limits, which region has better availability, which support tier actually gets responses. This knowledge took years to accumulate and is worthless on another platform.

Over time, hiring reinforces the pattern. Job descriptions ask for "3 years AWS experience." Candidates self-select. New hires bring more AWS knowledge, and the organisation's dependency deepens. Eventually, proposing a migration isn't just a technical discussion. It's a conversation about retraining an entire team, and nobody wants to have it.

The alternative is investing in transferable skills. Kubernetes administration works across providers. PostgreSQL expertise applies everywhere PostgreSQL runs. Prometheus, Grafana, GitOps with Flux or Argo: these are skills that travel. Engineers who understand the underlying standards can work on any implementation.

This doesn't mean ignoring provider-specific knowledge. It means building expertise in layers: standards at the foundation, provider-specific optimisations on top. When the foundation is portable, the provider-specific layer is thin enough to rebuild.

How the Walls Reinforce Each Other

What makes cloud lock-in so effective is that these four forces work together. Technical dependencies make data migration harder. Data gravity makes contractual negotiations weaker. Contractual commitments fund training in provider-specific skills. Provider-specific skills make technical dependencies feel natural rather than constraining.

Breaking free from one wall while the others remain intact is exhausting. You might containerise your application to escape technical lock-in, but if your data is gravitationally bound and your team only knows one platform, the containerisation doesn't actually give you the freedom to move.

This is why lock-in strategies need to address all four dimensions. Portable technology choices, standard data formats with tested export procedures, contracts with explicit exit terms, and teams whose core skills are transferable.

The European Dimension

For European organisations, cloud lock-in has an additional layer. When you're locked into a US hyperscaler, you're not just locked into a vendor. You're locked into a jurisdiction, a regulatory framework, and an economic relationship where value flows across the Atlantic.

The EU Data Act's switching provisions, the ongoing discussions around EUCS (European Cybersecurity Certification Scheme), and the broader push for digital sovereignty all reflect a growing European consensus: lock-in isn't just a commercial inconvenience. It's a strategic vulnerability.

Building on open standards, European providers, and transferable skills doesn't eliminate all risk. But it keeps the walls from going up around you. And that's what sovereignty means in practice: not isolation, but the maintained ability to choose.

Sources:

• EU Data Act: Cloud Switching Requirements (Latham & Watkins, 2025)
• 37signals Cloud Exit Savings (DHH)
• Broadcom VMware Price Increases 800-1,500% (The Register, 2025)
• DynamoDB Migration Challenges (ScyllaDB)
• AWS Data Transfer Pricing

#lockin #sovereignty #strategy #portability #europeancloud