Isn’t some lock-in worth it for the productivity?

Often, yes. Deep managed services can genuinely speed up a small team, and refusing all of them can cost you velocity. The point is not to avoid lock-in absolutely, but to take it on deliberately, with the exit cost priced in, rather than drifting into dependencies you never chose. Some are worth it; the trap is the ones you do not notice.

Does the EU Data Act remove lock-in?

It removes part of it. The Data Act strips out egress fees and unenforceable contractual barriers, which is the financial half of lock-in. It does nothing about the technical half: proprietary APIs and managed services your own architecture depends on. The legal right to leave is now yours; the engineering ability to leave still has to be designed in.

How do I measure my lock-in?

Look at the four mechanisms for each critical workload: how much data you would move and at what egress cost, how many proprietary services have no drop-in equivalent, how much of your team’s skill is vendor-specific, and what contracts penalise leaving. The workloads where all four are high are the ones where you have the least freedom and the most exposure.

The mechanics of lock-in

Cloud vendor lock-in and why it is a strategic risk

Vendor lock-in is usually described as a technical inconvenience. It is really a strategic and, increasingly, a legal risk: it decides your pricing power, your resilience, and whether you can comply with rules that now demand an exit plan. This page breaks lock-in into its actual mechanisms (data, interfaces, skills and contracts), explains why egress pricing made it worse, and sets out what reversibility looks like as a design goal.

This is general information about vendor lock-in and the rules that touch it, not legal advice. For your obligations, ask a qualified lawyer.

What lock-in actually is

Lock-in is the accumulated cost of leaving a provider, measured in money, time and risk. It is not a single feature you can point at; it is the sum of every dependency your system has grown on one vendor’s specific way of doing things. The higher that cost, the less real your ability to renegotiate, to leave, or to survive the provider’s outage or price rise.

It matters because it inverts the power in the relationship. A provider you cannot credibly leave sets the terms: the price increases, the deprecations, the regional choices. Lock-in is the difference between being a customer and being captive, and most estates drift into it one convenient managed service at a time.

The four kinds of lock-in

Data gravity is the first: as your data grows, the cost and risk of moving it grows with it, and egress fees put a direct price on the exit. Interface lock-in is the second: proprietary APIs and managed services (a specific serverless model, a proprietary database, a vendor-only queue) that have no drop-in equivalent elsewhere, so leaving means rewriting, not repointing.

The third is skills: your team learns one provider’s console, IAM model and tooling, and that expertise is an asset that argues against ever moving. The fourth is contractual: committed-spend discounts, multi-year agreements and marketplace entanglements that make leaving a financial event, not just an engineering one. Real lock-in is usually all four at once.

Why egress pricing turned a technical issue into a moat

Charging customers to remove their own data is the clearest expression of lock-in as a business model. Egress fees are asymmetric: bringing data in is free, taking it out costs per gigabyte, and at scale that bill alone can stall a migration. It was never primarily about recovering network cost; it was about making the exit expensive enough to reconsider.

This is why the EU Data Act singled egress charges out for removal. The regulator recognised that a fee designed to punish leaving is an obstacle to competition, not a cost of service. As those charges phase out, the financial half of lock-in weakens, and what remains is the technical half you built yourself.

Reversibility as the antidote, designed in not bolted on

Reversibility is the deliberate opposite of lock-in: architecting so that leaving is a planned, rehearsed operation rather than a rewrite. In practice it means preferring open interfaces and portable formats over proprietary ones, keeping infrastructure as code that is not welded to a single vendor, and knowing, for each critical service, what the exit looks like before you need it.

It is rarely free, and it involves real trade-offs: the most portable choice is sometimes less convenient than the deepest managed service. But reversibility is now also a compliance asset. DORA requires tested exit strategies for financial entities, and the Data Act hands you the legal right to switch. Designing for reversibility is how you make both of those real rather than theoretical.

The trade-off nobody should flatten

There is a genuine tension here, and pretending otherwise would be dishonest. Deep managed services exist because they are productive: a proprietary serverless platform or managed database can let a small team ship faster than a portable, self-managed stack would. Avoiding all lock-in can mean giving up real velocity. "Never use a managed service" is as naive as "portability does not matter".

The honest position is that lock-in is a cost to be priced, not a sin to be avoided at all costs. Some dependencies are worth taking on for the leverage they give you; others are traps you back into without noticing. The point of naming the four mechanisms is to make that a decision you make on purpose, with the exit cost visible, rather than one you discover the day you need to leave.

Common questions about lock-in

Isn’t some lock-in worth it for the productivity?: Often, yes. Deep managed services can genuinely speed up a small team, and refusing all of them can cost you velocity. The point is not to avoid lock-in absolutely, but to take it on deliberately, with the exit cost priced in, rather than drifting into dependencies you never chose. Some are worth it; the trap is the ones you do not notice.
Does the EU Data Act remove lock-in?: It removes part of it. The Data Act strips out egress fees and unenforceable contractual barriers, which is the financial half of lock-in. It does nothing about the technical half: proprietary APIs and managed services your own architecture depends on. The legal right to leave is now yours; the engineering ability to leave still has to be designed in.
How do I measure my lock-in?: Look at the four mechanisms for each critical workload: how much data you would move and at what egress cost, how many proprietary services have no drop-in equivalent, how much of your team’s skill is vendor-specific, and what contracts penalise leaving. The workloads where all four are high are the ones where you have the least freedom and the most exposure.