The cheapest technology contract can become expensive when a company later discovers that moving away is difficult. As cloud, software and data systems become more central to operations, exit costs are becoming a strategic business issue.
For years, enterprise technology procurement was dominated by the cost of getting in: licence prices, implementation fees, migration budgets and expected savings. Companies are now paying more attention to the cost of getting out.
That change reflects the growing strategic importance of vendor lock-in. Lock-in is not new. Businesses have always faced switching costs when they changed software suppliers, banks, logistics partners or equipment manufacturers. What has changed is the depth of dependency. A modern cloud platform can hold data, applications, security controls, analytics, identity services and artificial intelligence workloads at the same time. Replacing it may therefore mean redesigning a large part of the operating environment rather than simply changing a supplier.
The result is a broader understanding of technology cost. Procurement teams still care about annual fees, but boards are increasingly interested in portability, interoperability, contractual exit rights, data-transfer economics and the availability of substitute suppliers. A system that is cheap to buy but difficult to leave can carry a large hidden liability.
Cloud computing made the lock-in debate unavoidable
The cloud market has made these questions particularly visible because infrastructure decisions can shape the architecture of a business for years. The UK's Competition and Markets Authority completed a major investigation into cloud infrastructure services in July 2025. Its final decision recommended that the CMA consider strategic market status investigations into Microsoft and Amazon Web Services, reflecting concerns about competition and customers' ability to switch or use multiple providers.
The investigation followed an earlier Ofcom market study that identified factors capable of making switching and multi-cloud strategies harder, including data egress charges, technical barriers and committed-spend discounts. None of those mechanisms is automatically improper. Large discounts can lower costs, and proprietary services can provide genuine technical advantages. The concern is what happens when the same features also make the customer progressively more dependent on one provider.
The distinction matters because dependency compounds. A company may begin with basic computing and storage, then adopt a provider's database, analytics, cybersecurity, AI and development tools. Each decision can be rational on its own. Collectively, however, they can increase the cost and complexity of changing provider.
Exit costs are wider than data-transfer fees
Cloud egress fees became an obvious symbol of lock-in because customers could be charged to move data out of a platform. Major providers responded. Google Cloud announced in 2024 that customers closing their environment could obtain free network data transfer when migrating to another provider or on-premises. AWS introduced a similar policy for customers moving out of AWS, subject to its process for verifying migration-related transfers.
Those changes reduce one visible switching cost, but they do not eliminate lock-in. The largest cost of leaving a platform is often the engineering effort required to replace proprietary services, rewrite integrations, retrain staff and redesign operational controls. Data may be portable while the application that depends on the data is not.
There are also organisational costs. Employees become skilled in one supplier's tools, procurement processes are built around the relationship and internal support models adapt to the chosen architecture. A switch can therefore require technical migration, contractual change and workforce retraining simultaneously.
Regulators are pushing portability higher up the agenda
Policy is moving in the same direction. The European Union's Data Act contains measures intended to make switching between data-processing services easier. The broader regulatory objective is to reduce obstacles that prevent customers from moving between providers or using several services together.
The business significance is important even for companies outside Europe. Once large technology markets begin demanding clearer switching terms, portability can become part of global product design. Providers may decide that maintaining entirely different commercial and technical models by jurisdiction is inefficient.
For customers, regulation should not be mistaken for a substitute for architecture. Legal rights to move data do not guarantee that a system can be migrated quickly. A company that wants real optionality still has to design for it.
Companies are starting to price optionality
This is changing procurement. The value of a technology contract is increasingly being assessed not only through expected savings but also through the options it preserves. Can the customer export its data in usable formats? Are interfaces documented? Can workloads run elsewhere? Does the contract contain reasonable termination assistance? Are there substitute suppliers with sufficient scale?
The economics resemble insurance. Building portability can look inefficient while the primary supplier is performing well. Maintaining abstraction layers, duplicated capabilities or second-provider expertise can add cost. The benefit appears only when conditions change: prices rise, service quality falls, a strategic requirement changes or a supplier experiences an outage or security incident.
This is why lock-in cannot be eliminated completely. A company that refuses every proprietary feature may give up innovation and efficiency. The more practical objective is to know where the organisation is intentionally accepting dependency and whether the commercial benefit is large enough to justify it.
The AI boom is creating a new generation of dependencies
Artificial intelligence is likely to make the issue more complex. Enterprise AI systems increasingly depend on external foundation models, specialist data, cloud accelerators and managed development platforms. The Bank of England and FCA found in their financial-services AI survey that a third of current AI use cases were third-party implementations. The top three named cloud providers accounted for 73% of cloud-provider references, while the top three model providers accounted for 44%.
Financial services is only one industry, but the pattern illustrates a wider concern. Companies can become dependent not only on the infrastructure provider but also on the model, the model's application programming interface, its safety policies and its pricing structure. If a provider changes a model or retires a version, the customer may have to re-test workflows or redesign controls.
This makes model portability and data lineage part of the lock-in discussion. Enterprises need to know whether they can change models without rebuilding the whole application, whether prompts and evaluation data are reusable, and whether proprietary tools are becoming embedded in critical workflows.
Multi-vendor strategies are useful but not free
A common response is to diversify. Multi-cloud and multi-vendor strategies can reduce dependence on one supplier, improve negotiating leverage and provide resilience. But diversification can also create duplicated costs, integration complexity and more difficult security management.
Running the same workload across several clouds is rarely as simple as copying it. Services differ, operational procedures differ and teams need expertise across multiple environments. For many companies, the right answer may be selective diversification: maintain genuine alternatives for the most critical workloads while accepting deeper dependency where switching would be less consequential.
That approach requires classification. Companies need to distinguish between vendors that are convenient and vendors that are structurally difficult to replace. The latter deserve more rigorous exit planning, stronger contract terms and clearer board visibility.
Vendor concentration is becoming a board issue
Lock-in was once treated mainly as a negotiation problem for procurement and IT. It is increasingly becoming an operational-resilience and strategy problem. A critical provider can influence the company's cost base, pace of innovation, cyber exposure and ability to recover from disruption.
That does not mean vendor concentration is always bad. Large suppliers often deliver scale, sophisticated security, global infrastructure and rapid product development that smaller firms cannot easily match. The challenge is that the same scale can make replacement harder once the customer has deeply integrated the platform.
Boards therefore need a more nuanced question than 'are we locked in?' Most large enterprises are locked in somewhere. The useful questions are where, why, for how long, and at what cost to reverse the decision.
How to calculate the cost of dependence
One reason vendor lock-in persists is that companies rarely calculate it explicitly. The annual contract price appears in a budget, but the future cost of migration is spread across technology, people and operations. A more complete assessment would estimate data extraction, application redesign, integration replacement, testing, retraining, dual-running costs and the business disruption associated with a move.
The exercise does not need to produce a perfectly precise number. Its value is comparative. Two suppliers with similar annual prices may create very different exit liabilities. One may rely heavily on open standards and portable data, while the other depends on proprietary services that become increasingly difficult to replace. A procurement decision looks different when the organisation places a plausible cost on reversing it.
Contracts can also create soft lock-in. Minimum-spend commitments, bundled discounts, long renewal cycles and termination notice periods may all make switching economically unattractive even where the technology is technically portable. Staff incentives matter too: if teams are rewarded for rapid deployment but not for long-term maintainability, they may rationally choose the fastest proprietary option and leave the exit problem for someone else.
For critical vendors, companies can therefore treat exit readiness as an operating metric. The organisation might track when data was last exported successfully, how long a migration would take, which replacement suppliers are viable and where undocumented dependencies remain. That turns lock-in from an abstract concern into something management can monitor over time.
The hidden liability is loss of choice
Vendor lock-in becomes expensive when it removes the ability to respond to change. A company may discover that it cannot negotiate effectively because migration would take years. It may delay adopting a better product because the integration costs are too high. It may accept weaker service because the operational risk of moving is greater than the inconvenience of staying.
This is why optionality is becoming a measurable business asset. Companies do not need to build every system for immediate portability, but they need to understand the price of dependence before that dependence becomes irreversible.
The cheapest supplier is not always the lowest-cost supplier over the life of a system. In an economy built increasingly on cloud, software and AI platforms, the ability to leave may become almost as valuable as the ability to join.
That makes exit planning a commercial discipline rather than a pessimistic exercise. A company that periodically tests its ability to export data, document dependencies and identify alternative suppliers is not signalling that it expects the relationship to fail. It is preserving negotiating power and reducing the chance that a future strategic decision is constrained by yesterday's technology choices.
The strongest supplier relationships may actually benefit from this clarity. When both sides understand the customer's portability requirements, the relationship can compete on service, innovation and value rather than on the practical difficulty of leaving. That is a healthier basis for long-term partnership and a more accurate way to think about total technology cost.
There is also a governance benefit. When exit assumptions are documented, boards and audit committees can see which dependencies are deliberate and which have accumulated accidentally. That helps distinguish a strategic partnership from an unmanaged concentration risk. It also creates a basis for deciding where additional resilience spending is justified and where the cost of duplicating capability would outweigh the benefit.
The broader lesson is that lock-in should be treated as a lifecycle cost. Procurement teams may still choose a highly integrated supplier because the productivity gains are worth it, but the choice is stronger when the future exit burden is visible at the outset. A company does not need maximum portability everywhere; it needs enough portability in the places where losing choice would materially constrain strategy.
References
1. UK Competition and Markets Authority — Cloud services market investigation
2. Ofcom — Cloud services market study final report
3. Google Cloud — Removing data transfer fees when moving off Google Cloud
4. AWS — Free data transfer out when moving out of AWS
5. European Commission — Data Act
6. Bank of England and FCA — Artificial intelligence in UK financial services 2024