The condition where an organization becomes dependent on a single vendor’s technology to the point where switching to an alternative would be prohibitively expensive, disruptive, or both.
Lock-in gets treated as something vendors do to you. In practice, most of it is something organizations do to themselves through years of integration decisions, custom configurations, and workflow dependencies that nobody documented.
Deliberate vs. accumulated dependency
Some lock-in is by design. A vendor builds proprietary data formats, closed APIs, or pricing structures that make migration painful. That’s the kind everyone warns about, and it’s the easiest to spot during procurement.
The more common variety is accumulated. A team customizes the platform with proprietary scripting. Another team builds 40 automated workflows that depend on the vendor’s specific logic. A third team trains 200 people on the interface. Five years later, the organization technically could switch vendors but practically can’t, because the migration would require rebuilding every workflow, retraining every user, and rewriting every integration.
The real question isn’t whether, it’s where
Zero lock-in is a fantasy. Every technology choice creates some dependency. Choosing a data warehouse locks you into its SQL dialect and connector ecosystem. Choosing a CRM locks you into its object model and automation logic.
The useful question is whether you’ve chosen where to accept dependency and where to insist on portability. Data should almost always be portable. Workflow logic is harder. User training and institutional knowledge are the stickiest lock-in of all, and no contract clause addresses them.