Vendor Lock-In Is Not a Problem. It Is a Strategy.

I have written about vendor lock-in three times now across different posts. I called it a deliberate platform strategy in one. I traced it through Pfeffer and Salancik's resource dependence lens and showed how IT sourcing creates structural dependency in another. In a third I showed how AI model providers are the most concentrated critical resource the IS field has encountered. What I have not done is name the thing directly, which is that lock-in is not a problem that needs solving. It is a strategy that needs understanding, and both sides are playing it.

Let me start with the theory most people reach for. Transaction cost economics says that lock-in happens when asset specificity is high. Williamson (1975, 1985) built the framework around a deceptively simple observation: when you invest in assets that have high value inside a specific relationship but low value outside it, you create a condition where exit is costly. The logic is clean. An organization builds on AWS, writes code against Lambda and DynamoDB and API Gateway, integrates SageMaker pipelines into its ML workflow, and that code does not run anywhere else. Every layer of integration is a specific investment that becomes nearly worthless if the relationship ends. TCE predicts this outcome and explains why it persists. High asset specificity means high switching costs means high transaction costs means the market relationship continues even when the buyer would prefer to leave.

What TCE does not explain well is the other side of the table. Asset specificity is not a weather pattern that happens to organizations. It is something vendors cultivate deliberately and something buyers accept knowingly. This is where Pfeffer and Salancik (1978) give us a sharper lens. Their argument in The External Control of Organizations is that organizational behavior is shaped by the need to secure critical resources from external actors. When resource providers are few and the resources are important, the dependent organization loses discretion over its own strategy. Power flows toward whoever controls what the organization needs. The key word is "controls." This is not a passive condition. The resource provider acts to maintain and deepen that control. And I think this reframing matters because it changes the question from "how do organizations escape lock-in?" to "why do organizations enter lock-in relationships, and what do vendors do to keep them there?"

AWS offers hundreds of managed services. Each one is genuinely useful. Lambda saves engineering time. DynamoDB scales without provisioning. CloudFormation automates infrastructure. Nobody forces you to use them. A cloud architect could choose to run everything on EC2 instances with open-source tooling and keep the architecture portable. Almost nobody does this at scale because the managed services are better, cheaper in developer time, and operationally simpler. The vendor provides genuine value and simultaneously constructs a dependency that compounds with every new service adopted. These two facts exist at the same time. The value is real. The dependency is real. Acknowledging one does not negate the other.

I wrote about this before as a deliberate platform strategy, and I want to push the argument further here. Parker, Van Alstyne, and Choudary (2016) described how platforms grow by expanding their ecosystems, and every expansion makes the platform more useful and harder to leave. That is not a bug in the platform model. It is the model. But what I did not emphasize enough in that earlier post is that organizations are not surprised by this. Cloud architects know that every AWS-specific integration adds to the switching cost. Procurement teams know that SaaS contracts auto-renew and that the renewal notice window is sixty days. CIOs know that moving off a platform after seven years of customization will cost millions. They sign the contracts anyway. And they are not being irrational.

Organizations accept lock-in because the alternative is often worse. Running your own infrastructure requires a different set of capabilities, costs, and risks. Multi-cloud architectures that preserve portability carry a complexity premium that most organizations cannot or will not pay. The organizations I have seen that maintain genuine switching credibility, meaning they could actually move if they needed to, are the ones that have invested in internal platform teams, standardized on open interfaces, and accepted a slower velocity in exchange for strategic flexibility. That investment is real and ongoing. Most organizations decide, reasonably, that the flexibility premium is not worth it.

Pfeffer and Salancik laid out the responses to dependency that organizations can pursue. Absorption through vertical integration, which means building the capability internally. Substitution, which means finding alternative resources that reduce the criticality of any single provider. Diversification across multiple providers. And political coalition, which means building collective bargaining power with other dependent organizations. Every one of these maps to real IS strategy decisions. Building internal platform capability is absorption. Adopting open-weight AI models instead of proprietary APIs is substitution. Running multi-cloud is diversification. Industry consortiums that negotiate with hyperscalers are political coalition. None of these is free. Each one trades one type of cost for another. The multi-cloud organization pays in operational complexity. The open-weight adopter pays in infrastructure and talent. The building organization pays in engineering time and opportunity cost.

The reason I keep returning to this is that the IS literature, and most practitioner writing, treats lock-in as something that happens to organizations, a trap they fall into, a mistake they made in the procurement process, an oversight in contract negotiation. That framing removes agency from both sides. The vendor designed the trap. The buyer walked into it with open eyes. The game has rules and both players know them. AWS is not hiding the fact that Lambda is proprietary. Salesforce is not concealing that Apex code is non-portable. The switching costs are visible to anyone who reads the architecture documentation. What makes the game work is that the short-term incentives align for both parties. The vendor gets a committed customer. The customer gets a product that works well right now. The long-term cost, which is the loss of strategic discretion, gets discounted, sometimes formally in a business case, sometimes informally because the people who will deal with it are not the people making the decision.

Clemons and Row (1992), building on TCE, showed that IT changes the structure of transaction costs in a way that moves firms toward long-term cooperative relationships rather than pure market exchanges or full hierarchical ownership. Their "move to the middle" argument suggested that IT reduces coordination costs but does not reduce the risks that come with asset specificity. The relationship is stable, but stability and autonomy are not the same thing. A locked-in relationship can be stable and profitable for both parties while still leaving one party with substantially less control over its own strategic direction. That is the condition most large organizations find themselves in with their primary technology vendors. Stable, productive, and dependent.

I think the most honest way to frame vendor lock-in is as a strategic tradeoff that organizations make with full knowledge of the terms. The vendor's strategy is to create conditions where staying is easier than leaving. The organization's strategy, when it is deliberate, is to accept the dependency in exchange for capability and velocity, while maintaining enough switching credibility to avoid the worst forms of exploitation. When the organization has no strategy at all, it drifts into dependency by accumulation: one service at a time, one integration at a time, one contract renewal at a time, until the switching cost has grown past the point of rational exit. That is not a trap. That is a game played without strategy, and the opponent has one.