Vendor lock-in: measure the cost of leaving, not the cost of entry
The question when adopting a platform is not only what it costs to get in. It is what it would cost to get out - and whether you can honestly answer that before signing.
Every significant technology purchase involves some degree of lock-in. You adapt processes, integrate systems, train people, and accumulate data in the vendor's format. That is normal and not inherently bad - the question is whether you went in with eyes open.
Most vendor evaluations I see focus on entry costs: licensing, implementation, training, migration. The exit cost rarely appears in the analysis. It is assumed to be hypothetical, too far in the future to matter, or simply not calculated because nobody wants to start a vendor conversation by talking about leaving.
In 2016, with cloud adoption accelerating, this gap in evaluation is becoming more expensive. Proprietary cloud services are easy to adopt and hard to exit. The economics of lock-in are becoming something that management teams need to understand explicitly.
What exit costs actually include
When I work through vendor lock-in with a client, I try to quantify exit costs across a few categories.
Data portability: Can you export your data in a standard, usable format? What is excluded from the export? How long would it take to move a full dataset? Some vendors charge for bulk data exports. Some formats require transformation work before they can be loaded elsewhere.
Integration surface: Every integration point you build to a vendor's proprietary API is a point you have to rebuild if you leave. A system with 12 downstream integrations to a vendor's specific API has a much higher exit cost than one using a generic standard like REST with a published schema.
Knowledge and process: How much of your team's operational knowledge is specific to this vendor's platform? If the answer is "most of it," the exit cost includes retraining or re-hiring, which rarely appears in financial models.
Contractual terms: Minimum commitments, auto-renewal clauses, and data retention after termination. These are negotiable at signing and almost impossible to change later.
The portability conversation to have before signing
I recommend asking any potential vendor three specific questions before signing:
First, what does a full data export look like in practice - not in the documentation, but in terms of a real export of your expected data volume, in what format, and at what cost?
Second, what happens to your data after contract termination, and for how long?
Third, are there features or integrations you plan to use that are available only through this vendor's proprietary APIs, with no standard alternative?
The answers will not always be dealbreakers. But they establish the honest picture of what you are committing to.
A balanced position
I am not arguing for avoiding all proprietary platforms. The productivity gains from well-integrated cloud platforms are real. The argument is for proportionality: the more tightly you integrate with a vendor's proprietary surface, the more explicit the exit strategy needs to be.
For core systems - anything your business would genuinely struggle to run without - the exit cost should be calculated and reviewed by whoever signs the contract. Not as a formality, but as an actual number.
For non-core tools, a lighter version of this analysis is fine. But "we didn't think about what happens when we need to leave" should not be how that sentence ends.