Vendor Lock-In

Vendor lock-in is the quiet economics of dependence: the costs — contractual, technical, and data — that make leaving a provider more expensive than staying, growing with every year you stay. It is not always bad; it is always a price. The discipline is knowing which one you're paying, and capping it deliberately.

What It Is

Vendor lock-in describes the mechanisms that raise switching costs: proprietary data formats that resist export, deep integration into your workflows, per-user contracts with enterprise pricing, APIs that are contractually constrained, knowledge that lives in the vendor's people, and commercial terms (credits, prepayment) that penalise departure. Lock-in is the strategy behind 'land and expand' — the entry price is low precisely because the exit price compounds. Its technical cousins are equally binding: a codebase nobody but one vendor understands, an architecture welded to one cloud's proprietary services.

Why It Matters to You

Lock-in is acceptable when chosen consciously and priced — every serious system creates some dependence, and the stability can be worth it. The executive failure is unconscious lock-in: dependence accumulated without a ledger. Manage it with contractual instruments (data export in documented formats as a contractual right, escrow for the source, exit assistance clauses, no unilateral API changes without notice) and architectural ones (open standards at the boundaries, your data modelled as yours, abstraction layers at the integration seams). The test question at every renewal: if we had to leave in twelve months, what would it cost and could we?

When You'll Meet It

At every significant procurement and renewal. Before signing, price the exit; during the relationship, guard the export rights; at renewal, re-run the question — dependence has a way of compounding quietly.