What concrete forms does vendor lock-in take beyond 'it's hard to switch,' and what should an exit strategy documented during vendor selection actually contain?

## The five concrete sources Vendor lock-in is often discussed as a vague feeling of dread rather than a set of specific, assessable mechanisms, which makes it hard to act on during selection. Concretely, lock-in comes from five main sources. - **Data lock-in**: the vendor stores your data in a proprietary schema or format, and extracting it requires custom transformation work, or the vendor's export tooling is limited, expensive, or slow. - **Integration lock-in**: your own application code calls the vendor's specific SDK or API surface directly throughout the codebase, so replacing the vendor means rewriting every call site, not swapping a config value. - **Contractual lock-in**: multi-year terms, auto-renewal clauses, early-termination penalties, or minimum-spend commitments that make leaving financially painful regardless of technical feasibility. - **Operational lock-in**: your team's runbooks, monitoring dashboards, and on-call knowledge are built around this vendor's specific tooling and quirks, so even a technically clean migration requires retraining and rebuilding operational muscle memory. - **Skills and organizational lock-in**: staff have been hired or trained specifically for this vendor's platform, and losing that vendor means losing the return on that investment. ## Why the exit strategy is written before signing An exit strategy is written during selection, before signing, because **that's the only point at which the buyer has real negotiating leverage**. Once a contract is signed and the system is in production, the vendor has no incentive to offer favorable exit terms, such as data-export assistance, reasonable termination notice, or capped early-termination fees, because the buyer's negotiating position has collapsed; asking for those terms after the fact is asking for a favor, not negotiating a deal. Writing the exit plan up front also forces the evaluation team to actually validate the technical exit path, verifying that data can really be extracted in a usable format, rather than assuming it will be fine, which is exactly the assumption that turns into a crisis later. ## The tension with getting full value There's a real tension between minimizing lock-in and getting full value from a vendor's product: the more deeply you integrate, using vendor-specific features and letting the vendor manage more of the operational surface, the more value you typically extract, but also the deeper the lock-in. A common architectural mitigation, wrapping every vendor call behind your own abstraction layer, reduces integration lock-in but: - costs ongoing engineering effort to build and maintain - can mean never fully using a vendor's differentiated features, because the abstraction only exposes a lowest-common-denominator interface Organizations have to consciously choose how much lock-in they're willing to accept in exchange for how much value, rather than treating 'avoid all lock-in' as a free win, because it isn't. ## Where it goes wrong 1. The classic failure is **discovering the true cost of lock-in only when trying to leave**: a team decides to switch data platforms and finds the vendor's export feature produces a format that takes months of engineering effort to actually parse and load elsewhere, or discovers the contract has an 18-month notice period with a termination penalty equal to a year of fees. 2. A second failure mode is **pricing lock-in**: a vendor offers an attractive introductory price, the org builds deep dependency over two to three years, and then the vendor raises prices sharply on renewal, knowing switching costs now exceed the increase — a well-documented pattern, and the reason renewal-pricing caps are worth negotiating up front. 3. A third failure is **assuming an abstraction layer protects you when it was never actually kept up to date**: teams build a nominal interface early, then bypass it under deadline pressure for vendor-specific features, quietly recreating full lock-in behind a facade that looks like protection but isn't. ## A worked example A company selecting a workflow-automation SaaS platform negotiates, before signing: - a clause guaranteeing data export in a documented open format within 30 days of a termination request - a capped early-termination fee of three months of fees rather than the remainder of the contract - 90 days' notice before any price increase above 5% year-over-year During RFP evaluation they also run a test: they ask each finalist vendor to actually perform a sample data export as part of the POC, and time how long it takes and how usable the output is — one finalist vendor's export turns out to omit workflow history entirely, a gap only surfaced by testing exit mechanics before signing rather than trusting a marketing claim. That finding removes the vendor from consideration even though its functional features scored well, because an exit-path failure would have created a multi-year hostage situation had it surfaced only after adoption.