The Vendor Lock-In Decision Framework

Vendor lock-in has exactly two costs: the expense of migrating away if that becomes necessary, and whatever pricing leverage the dependency gives the vendor. Both are quantifiable. Using vendor-specific capabilities is not itself a cost — it is an investment with a knowable exit price.

The standard advice to avoid lock-in through abstraction inverts the economics. Portability is paid for continuously, in exchange for an option that most organizations never exercise.

The cost of avoiding lock-in

Cloud-agnostic architecture carries specific, recurring expenses:

• Abstraction layers requiring maintenance as each underlying provider's API changes, on a schedule set by the providers
• Lowest-common-denominator capability, since the abstraction can only expose what all targets support — which excludes the managed capabilities that justified the platform
• Indirection overhead, in latency and in the difficulty of diagnosing failures through an extra layer
• Engineering time spent on portability rather than on product
• Untested portability. An abstraction layer never exercised against a second provider does not work against a second provider. Teams that build cloud-agnostic infrastructure and later attempt migration commonly find the abstraction leaked provider-specific behavior anyway.

The frequent outcome is neither platform benefit nor real portability.

The question that produces a better answer

Replace "does this create lock-in" with "how hard is extraction, and from what." Dependencies fall into tiers with materially different exit costs.

• Infrastructure primitives — compute, object storage, managed relational databases, message queues. These are commodities with equivalents at every provider. Migration is tedious, well-understood, and estimable. Locking in here carries low risk.
• Managed platform services — serverless compute, managed identity, API gateways. Moderate extraction cost, largely determined by how much application logic has been placed inside them rather than adjacent to them.
• Proprietary data formats and stores — anything holding core business data in a format with no export path to an equivalent. High extraction cost. Selectivity is warranted.
• Business logic in vendor workflow services — rules encoded in a proprietary orchestration or low-code engine. Highest extraction cost, because the asset being locked in is the business itself rather than infrastructure.

The tier determines how much scrutiny a dependency deserves. Applying uniform caution across all four tiers is what makes the standard advice expensive.

Design for extraction, not portability

The mitigation is code organization, applied at the boundary rather than throughout.

• Keep platform services as thin adapters. A serverless function that parses an event, calls domain logic, and formats a response has a migration surface consisting of the parse and format steps.
• Keep domain logic free of platform SDK types. The rule is enforceable in review and costs nothing at runtime.
• Own the data. Ensure a documented, tested export path exists for every store holding core business data, and verify it periodically rather than assuming it.
• Record the exit cost. For each significant dependency, maintain a current estimate of what replacement would require. That estimate is the input to both the risk conversation and the pricing conversation.

This produces the same protection the abstraction layer was intended to provide, without the continuous cost, because it is a constraint on where code lives rather than a runtime component.

When portability is a genuine requirement

Some situations require real multi-provider architecture, and there the investment is justified:

• Regulatory data residency obligations across jurisdictions no single provider covers
• Enterprise customers contractually requiring deployment into their own cloud accounts
• Infrastructure software whose product definition includes running anywhere
• Concentration risk at a scale where a provider outage is an existential business event

These call for the full commitment — container orchestration, genuine abstraction, and continuous testing against every supported target. Half-measures in this category deliver the cost without the capability.

Using the exit cost as leverage

A documented, credible migration estimate is the input to a renewal negotiation, and it only functions if it is credible.

Vendors negotiate with customers at spend levels where the account matters, and a customer who can specify what migration would cost and how long it would take is negotiating from a different position than one asserting the option in general terms. The portability is realized at the point it is needed, financed by not having maintained it in the interim.