Vendor lock-in
The state where switching provider is so costly, slow or contractually blocked that you cannot leave in practice, whatever the contract says you may do.
Lock-in is the quiet way sovereignty is lost, by an accumulation of conveniences that harden into constraints.
Lock-in rarely arrives as a choice. It accumulates. A managed service here, a proprietary format there, a control plane you build your runbooks around, and one day leaving would cost more than staying, so you stay. That is the mechanism, and it is why a workload that cannot move cannot really be owned.
It has several faces: proprietary services with no open equivalent, data formats only the vendor can read, provider-specific APIs woven through your code, identity and secrets tied to the provider’s control plane, skills and tooling that assume one supplier and commercial terms such as egress fees or minimum commitments. Each one is a switching cost, and the total switching cost is the real measure of lock-in.
The defence is to build the ability to leave before you need it. Portability, open formats and an executable exit clause are the three levers that keep switching a genuine option.
Common misconceptions
We are not locked in, we can export our data whenever we like.
Data export is one dimension. Proprietary APIs, managed services with no equivalent, identity tied to the provider and egress fees can each turn leaving into a project.
Open source means no lock-in.
You can be locked into a specific managed distribution, a control plane or an operational model even when the source is open. Lock-in is a property of the whole system, and an open licence does not settle it.