The price of being able to leave

Why does keeping the freedom to change supplier often cost more than being tied to one?

Two teams build the same service. The first uses the platform's managed queue, its managed database, its identity service, its scheduler. The second wraps every one of those behind an interface of its own, so that nothing in the application knows which supplier is underneath.

The second team is doing the responsible thing, we tend to assume. But watch what they have actually bought: more code, an abstraction to maintain, and features they cannot use because the interface only admits what every candidate supplier supports. They will be slower to ship, forever, in exchange for a migration that may never happen.

So the honest question is not should we avoid lock-in. It is: what exactly is being purchased with that ongoing slowness, and how do we tell when the price is fair?

Begin by noticing that portability is not a property. It is an ongoing expenditure. If nobody exercises it, an abstraction rots — the second supplier's driver goes untested, a leaky detail creeps into the application, and the layer that was supposed to guarantee escape quietly stops guaranteeing anything. Portability held but never used tends to be portability discovered, at migration time, not to exist.

Then ask what the abstraction can contain. It can only expose the intersection of what all the candidates do. The managed database's change-data-capture stream, its geo-replication, its query planner hints — if the fallback lacks them, they are outside the interface. So the cost is not merely writing the layer. It is a permanent tax on capability, paid in the present, for an option exercised in an uncertain future.

Now turn it around, because the other side is real too. What does lock-in actually cost when you are in it? Not just the migration bill. It is the price at renewal when the supplier knows what leaving would cost you; it is being carried along when they deprecate a service, change their licence, raise prices, or fail. Those are not hypotheticals, and a team with no exit has no argument in the room.

Which points at the useful reframing. What you are buying is not portability. It is an option — the right, not the obligation, to switch. And options have the properties finance gives them: they cost a premium up front, they are worth more when the future is uncertain, they are worth more when the underlying thing is expensive, and they expire worthless if never exercised. Notice how much better that framing behaves than "avoid lock-in". It tells you to ask how likely is the switch, how bad is the switch without the option, and what is the premium per year — three answerable questions in place of one slogan.

Then a distinction that does most of the practical work: portability is not uniform across a system. Which parts would actually be hard to move?

Your data and its history are the deep tie — and the hardest to reverse, because the volume grows monotonically and egress is charged. Your operational knowledge is another, less visible one. But the compute layer, the queue, the object store? Those are largely commodity, often standard-shaped, and cheap to keep loose. The layers differ by an order of magnitude in both switching cost and abstraction cost, and they should not receive the same policy.

One honest caveat: none of this yields a formula. The probability that you will switch suppliers in five years is not knowable, and anyone quoting a number for it is guessing. The framing improves the argument; it does not settle it.

Three refinements.

First, the misconception: portability is usually treated as a binary the architecture either has or lacks. It is better read as a price list. For each component, roughly what would it cost to move, and roughly what does staying loose cost per year? Written out, most systems show a handful of items worth real money and a long tail worth almost nothing — and the abstraction effort is nearly always spread evenly across both, which is where the waste lives.

Second, some portability is nearly free and should simply be taken. Keeping data in open formats, keeping schemas and pipeline definitions in your own repository, avoiding proprietary extensions where a standard one is equally good, exporting your own backups: none of these slow you down materially. Free options are always worth holding.

Third, and most practically: the exit that has never been rehearsed is not an exit. If the option matters, spend a little of the premium proving it works — restore a backup somewhere else, run one workload on the alternative, price the egress. That is the difference between an option and a belief in one.

• Data gravity: why accumulated data and egress pricing make storage the stickiest layer of all.
• Whether an abstraction layer that is never exercised provides any portability at all.
• Negotiation leverage as a distinct payoff from portability, separate from ever actually migrating.

Every term the collection defines is gathered in the glossary.