Avoiding lock-in versus paying for portability
Lock-in is real, and most of what is done about it is a bad trade. Designing for portability means declining managed services and rebuilding their equivalents, which is engineering time spent every year on an option that is usually never exercised. The better framing is financial: an exit has a price, portability has a price, and you should know both before deciding which to pay. Some hedges are nearly free and worth keeping permanently. Others cost more each year than the migration they are meant to avoid.
Which kinds of lock-in are actually hard to reverse?
Data gravity and commercial commitments, mostly. The technical dependencies people worry about, proprietary APIs and managed services, are usually the cheapest to unwind, because they are bounded pieces of code that a team can rewrite with a known effort. The expensive ones are the things that cannot be rewritten: petabytes that take weeks to move, a query layer that thirty teams have built reports against, and a multi-year spend commitment with a shortfall penalty attached.
It is worth separating them because the mitigations differ completely. You reduce data gravity by choosing open storage formats and keeping a copy of raw data outside the proprietary layer, which costs storage. You reduce commercial lock-in by matching commitment length to your planning horizon, which costs discount. Neither involves refusing to use a managed queue.
The third expensive category is organisational. A team that has spent four years learning one provider's identity model, networking and failure modes carries knowledge that does not transfer, and the productivity dip during a move is real and rarely budgeted. This is the same cost that makes a second provider expensive to add, viewed from the other direction.
| Type of lock-in | Reversal difficulty | Cost to hedge against it | Worth hedging? |
|---|---|---|---|
| Data volume and egress | High, measured in weeks | Storage for an open-format copy | Yes, for the datasets that matter |
| Analytics and query layer | High, many dependent consumers | Open table formats and a defined extract path | Yes |
| Committed spend agreements | High until the term ends | A lower discount tier | Sometimes, match term to horizon |
| Managed services and proprietary APIs | Moderate and boundable | Building and running the equivalents | Rarely |
| Identity and permission model | Moderate, rewrite of policy | Keeping access definitions in code | Yes, it is free anyway |
| Team knowledge | High, and invisible on a plan | Cross-training that decays without use | Only where already needed |
What does an exit actually cost?
Four buckets, and infrastructure is the smallest of them. Data movement, engineering time to rewrite provider-specific components, a period of dual running where both platforms are paid for, and the productivity loss while a team learns a new environment. A useful estimate can be assembled in a day by anyone who knows the estate, and the number is usually a surprise in both directions.
Data movement has become cheaper to reason about than it was. Providers now waive transfer charges for customers moving off entirely, and the EU Data Act, Regulation (EU) 2023/2854, removes switching charges including egress altogether from 12 January 2027. Until that date a provider may still lawfully charge a reduced, cost-based switching charge, so an exit priced now is not automatically free of one. The Commission's Digital Omnibus proposal of November 2025 would add relief for custom-made data processing services and for SMEs on contracts concluded before 12 September 2025, and it does not move the 12 January 2027 date. Either way the constraint is increasingly time and coordination rather than a transfer bill. What remains expensive is moving data that is being written to continuously, because the cutover has to be designed rather than scheduled.
The rewrite bucket is where estimates go wrong, and the error is directional. Teams overestimate the difficulty of replacing a managed queue or object store, which have close equivalents everywhere, and underestimate the work in identity, networking, deployment pipelines and everything that was configured once and never documented. When rehearsals are run, the surprises are almost always in that second category.
Which portability hedges are cheap enough to keep?
Five, and they are worth adopting whether or not you ever intend to move, because each pays for itself in operational terms. Containerise your applications. Keep infrastructure in code, with no console-created production resources. Keep raw data in open formats such as Parquet, with a defined extract path from any proprietary analytics layer. Use standard protocols where the provider's offering is compatible anyway. And keep your identity source of truth in a directory you control rather than in a single provider's native user store.
What these have in common is that none of them requires declining a managed service. You can run a managed Postgres, a managed queue and a managed object store while keeping every one of these properties. The hedge is in how the surrounding system is defined, not in refusing the useful parts of the platform.
The sixth cheap hedge is documentary rather than technical: an up-to-date list of every provider-specific dependency, with an owner. Most estates cannot produce this, which is why exit estimates are guesses. Producing it once and maintaining it as part of architecture review turns a multi-week discovery exercise into a lookup.
Which hedges cost more than they save?
Declining managed services in favour of self-hosted equivalents is the main one. Running your own database cluster, message broker, search cluster and secret store to stay portable means taking on patching, upgrades, capacity planning, backup verification and the on-call load for each, permanently, in exchange for a rewrite you would otherwise do once. For most teams the annual cost of that arrangement exceeds the one-off cost it avoids within a couple of years.
Writing an internal abstraction over multiple providers is the second, and it fails for an additional reason: it becomes a product with its own roadmap, its own bugs and its own maintainers, and it lags behind whichever provider ships something new. The detail is in the abstraction layer guide, and the summary is that abstraction converts a future migration cost into a permanent staffing cost.
Actually running production on two providers to stay warm is the third. It is the most expensive hedge available and it addresses lock-in only if both sides are genuinely capable of carrying the load, which requires the duplication to be maintained, tested and paid for indefinitely. That can be justified by resilience or by a contract, but as a lock-in mitigation alone it is poor value.
Do you need a second provider to negotiate at renewal?
No, it requires a credible alternative, which is a different thing. What moves a negotiation is a costed migration plan with a timeline, evidence that the technical dependencies have been identified, and a workload that could plausibly move first. Providers can tell the difference between that and a general statement about optionality.
The cheapest credible position is usually a single workload already running elsewhere, chosen because it was a reasonable fit rather than as a bargaining chip, plus the dependency inventory described above. That is a far smaller commitment than a balanced estate, and it demonstrates the capability that matters: that you can operate somewhere else when you decide to.
It is also worth knowing what is actually negotiable. Discounts scale with commitment, so threatening to remove spend reduces the discount rate on what remains, and the net position can be worse. Negotiating on term length, on ramp flexibility, on support tier and on migration or credit assistance frequently returns more than a threat to split the estate.
How do you price the option each year?
Run a two-part exercise annually. First, estimate the exit: pick your largest workload, list its provider-specific dependencies, and have the team that owns it estimate the engineering months to replace each, the data volume and cutover approach, and the dual-running period. Second, total what you are currently spending to remain portable, including self-hosted equivalents, abstraction maintenance and any idle second-provider capacity.
Compare the two numbers directly. If the annual portability spend approaches a meaningful fraction of the one-off exit cost, you are pre-paying for a move you may never make, and the money is better held. If the exit estimate is so large that it cannot be executed within any commercial timeframe, that is the signal to reduce specific dependencies, starting with data gravity and commitment length rather than with services.
The exercise has a side effect worth more than its output. It forces the dependency inventory to be current, which is the artefact regulators ask for, buyers ask for during due diligence, and your own team needs the day a real reason to move appears. Most organisations discover that maintaining the inventory is the mitigation, and everything else was optional.
Common questions
- What is cloud vendor lock-in?
- Dependency on one provider that raises the cost of leaving. It comes in several forms with very different reversal costs. Data volume and analytics layers are the hardest, because they are measured in weeks of movement and in the number of teams consuming them. Committed spend agreements bind commercially until the term ends. Managed services and proprietary APIs, the thing most people worry about, are usually the cheapest to replace because they are bounded pieces of code.
- Is it worth avoiding managed cloud services to stay portable?
- Usually not. Self-hosting the equivalents of managed databases, queues, search and secret stores means taking on patching, upgrades, capacity planning, backup verification and on-call load permanently, in exchange for a rewrite that would happen once. For most teams that annual cost exceeds the one-off cost it avoids within a couple of years, and the self-hosted versions are less reliable than the managed ones they replaced.
- What does it cost to migrate between cloud providers?
- Four buckets: data movement, engineering time to replace provider-specific components, a dual-running period where both platforms are paid for, and the productivity loss while the team learns a new environment. Transfer charges matter less than they did, since providers waive egress for customers leaving entirely and the EU Data Act removes switching charges including egress from 12 January 2027, though until that date a reduced, cost-based switching charge is still lawful. The underestimated bucket is identity, networking and deployment plumbing rather than applications.
- Which portability measures are actually worth taking?
- Five that cost little and pay off operationally regardless: containerise applications, keep infrastructure in code with no console-created production resources, keep raw data in open formats with a defined extract path from proprietary analytics, use standard protocols where the provider is compatible anyway, and keep the identity source of truth in a directory you control. A maintained inventory of provider-specific dependencies is the sixth and often the most valuable.
- Do you need a second cloud provider to negotiate better pricing?
- No, you need a credible alternative, which means a costed migration plan, an identified dependency list and a workload that could plausibly move first. Providers distinguish that from a general statement about optionality. Bear in mind that discounts scale with commitment, so removing spend lowers the rate on what remains. Term length, ramp flexibility, support tier and migration assistance often return more than a threat to split the estate.
