Vendor Lock-In Is a Strategy, Not an Accident

Most organizations realize they are locked into a vendor when they try to leave, not when they sign the contract. That sequence is not a coincidence. It is the vendor's strategy working exactly as designed.

I have been thinking about this because a pattern keeps repeating in enterprise IT conversations I follow. A company gets frustrated with Salesforce, or ServiceNow, or Oracle. Leadership decides to evaluate alternatives. The evaluation goes well until someone asks the migration question: what would it actually take to move? That is when the room goes quiet. The answer is usually "years" and "millions," and the alternative that looked attractive three months ago starts looking a lot less attractive. The switch never happens. The vendor renewal gets signed. Often with a price increase.

There is nothing accidental about how that situation comes to be.

The mechanism that creates lock-in is not one thing. It is a stack. At the bottom is data: your records, your history, your customer interactions, all stored in formats and schemas the vendor controls. Data can usually be exported, so data alone is not the trap. The trap is everything built on top of the data. In Salesforce, that means Apex code, custom objects, workflow rules, approval processes, and validation logic that have accumulated over years of customization. None of that logic is portable. It does not export. It lives only inside Salesforce's runtime environment, written in Salesforce's proprietary language, running on Salesforce's proprietary platform. When an organization tries to move to HubSpot or any other CRM, it faces a choice: rebuild all of that logic from scratch, or accept that the new system will not work the same way. Either option costs years of work and carries serious risk of breaking processes that the business depends on.

AWS does the same thing through a different mechanism. The cloud provider offers managed services that are dramatically more convenient than running your own infrastructure: Lambda for serverless compute, DynamoDB for key-value storage, SageMaker for machine learning workflows. Using these services is rational. They save engineering time. They scale automatically. They are good products. But every Lambda function you write, every DynamoDB table you design, every SageMaker pipeline you build is written against AWS-specific APIs. None of it runs on Google Cloud Platform or Microsoft Azure without a rewrite. The more of your system you move into managed services, the more rewriting a migration would require. And because AWS keeps adding services, the set of AWS-specific dependencies only grows over time.

ServiceNow is perhaps the clearest example of this dynamic. Their platform is sold to large organizations as a way to manage IT service management, HR workflows, and enterprise-wide approvals. Organizations take that pitch seriously. They spend years building processes on top of ServiceNow's proprietary workflow engine. The platform becomes the system of record for every approval, every change ticket, every onboarding task. At that point, leaving ServiceNow is not a software migration. It is a multi-year rip-and-replace project that touches every department in the organization. Consulting firms have built entire practices around SAP migrations, which have a similar profile, and they charge millions because the complexity of unwinding years of vendor-specific customization is genuinely enormous.

Transaction cost economics gives this a formal name. Williamson (1975, 1985) described asset specificity as one of the central drivers of transaction costs. When you invest in assets that have high value inside a specific relationship but low value outside it, you create a dependency. Williamson's original concern was physical assets, but the logic applies directly to vendor-specific customization. Every Apex class you write for Salesforce, every ServiceNow workflow you build, is an asset with near-zero value outside the vendor relationship. The investment is real. The portability is close to zero. This is exactly what vendors want. Once your specific investments are large enough, the economic case for switching becomes almost impossible to make.

Platform theory adds another dimension. Parker, Van Alstyne, and Choudary's work on platform ecosystems points out that platforms grow by expanding their ecosystem. Every additional product integrated through Salesforce's AppExchange, every new Microsoft 365 application connected to SharePoint and Azure Active Directory, every AWS service added to an architecture makes the platform more useful. And more sticky. This is not a flaw in the platform model. It is the model. The platform captures value as the ecosystem grows. Users perceive genuine benefits from integration. But the same integration that creates value also creates switching costs, because leaving the platform means leaving the entire ecosystem, not just one application.

Microsoft's approach to this is particularly clear if you watch it carefully. Teams, SharePoint, Exchange, Azure Active Directory (now Entra ID), and Azure cloud services are designed to work together so deeply that removing one requires renegotiating relationships with all the others. A company that moves off Azure still has Teams and SharePoint. But its identity management is now split between Entra ID and whatever identity provider it moved to. A company that moves off Teams still has Exchange. But its collaboration workflows are now fragmented. Each piece, taken alone, might seem replaceable. Taken together, they form an integration web that is extremely hard to unwind without disrupting the whole. I wrote about why platform governance structures reflect platform interests, not user interests, and Microsoft's product architecture is a textbook case of this logic in practice.

There is also a human capital dimension that gets underweighted in these conversations. The more people in an organization who are trained on Salesforce, certified on ServiceNow, or fluent in AWS, the more the organization has invested in vendor-specific skills that do not transfer easily. Even if a technically superior alternative exists, switching means retraining an entire IT organization and potentially losing staff who have built their careers on the incumbent platform's certifications. The switching cost is not just the migration project. It is also the productivity loss during the learning curve and the recruitment premium you pay for people already skilled in the new system.

The result is a situation where "best of breed" is largely theoretical. Procurement teams evaluate software in an idealized state, comparing capabilities side by side. But capabilities are only part of the decision. The real question is what it would cost to change your mind in five years. That question is almost never asked at the point of signing, because at that point the switching costs are zero. They accumulate slowly, through customization and integration and training, until leaving becomes economically irrational. And the vendors know this. Their product roadmaps, their professional services offerings, their partner ecosystems, and their pricing structures are all shaped by the goal of making that future calculation come out in their favor.

I wrote before about why enterprise software is universally hated but rarely replaced, and vendor lock-in is a big part of why the "rarely replaced" half of that sentence is true. The buyer who signs the contract has no lock-in problem. The buyer who inherits a system that has been customized for seven years has a very different calculation. The vendor built that gap on purpose.

Organizations that understand this should evaluate software contracts differently. The question is not just "what does this platform do today?" It is "what does our exit look like in year five, and who owns that exit cost?" The answer to that second question is usually already embedded in the vendor's architecture decisions. You just have to look for it.