Vendor dependency: calculate the exit cost before you sign
Why the cost of switching an IT vendor needs to be assessed upfront, and how it affects platform choice and contract terms.
When a company selects an IT platform - a cloud provider, an ERP system, a CRM, an infrastructure service - attention usually focuses on functionality, price, and implementation timelines. That is reasonable. But there is a question that rarely gets asked: what will it cost to leave, if that becomes necessary?
I am not advocating pessimism. Vendor dependency is not a problem in itself. It is a manageable risk that needs to be understood before signing a contract, not after three years of working inside someone else's ecosystem.
What the exit cost is made of
The exit cost is rarely just contractual - penalties and termination fees. It usually has several components.
Data. In what format is your data stored? Can it be exported in a standard form or only in a proprietary one? How long does a full export take and in what condition will the data be after migration? Companies frequently discover that data formally belongs to them but is effectively "locked" in a format nobody else reads without special tools.
Integrations. How many other systems are connected to this platform? Each integration is work that will need to be redone when the vendor changes. If after three years the platform has become the central hub for ten integrations, that is a significant amount of work.
Knowledge and skills. The team has learned to work with a specific platform. Switching means either retraining people or hiring new ones. That is time and money that appears in no contract.
Processes. Business processes adapt to the platform's constraints and capabilities. Sometimes so tightly that switching platforms effectively means reorganising processes.
When to think about this
The best moment is before the selection. Not because you should plan to leave from the start, but because understanding exit costs affects architectural choices, contract terms, and data storage strategy.
A few specific places where this shows up:
Data formats. Standard open format versus proprietary - this is a difference in migration cost. Worth discussing with the vendor during selection.
Contract terms. The right to export all data in a machine-readable format on request is a term that can and should be written into the agreement.
Architectural decisions. Some dependencies are created not by the vendor but by the development team - when a proprietary API is used where a standard one would work, or when application logic is written for a specific cloud function instead of portable code.
This is not an argument against specialised solutions
I want to be precise: vendor dependency is often justified. Deep integration with a good platform delivers real value. The question is not to avoid it, but to accept it consciously.
The difference between a managed dependency and an unmanaged one is whether you understand what it costs and what you would need to do to exit. If that understanding exists, the dependency is a strategic choice. If it does not, it is just accumulated risk.
Questions for assessment
- In what format can we export all of our data from this system?
- How many integrations with other systems will be involved in one year, in three years?
- What would we need to redo in processes and code if we changed vendor?
- Is the right to export data written into the contract?
- Is there an alternative vendor we could move to, and what would that require?