There is a number that does not appear in any enterprise AI budget document. It is not in the Microsoft earnings call, not in the Salesforce investor deck, not in the ServiceNow analyst day presentation. The number is the cost of undoing what the enterprise has already built.
Switching costs accumulate before anyone notices them. That is what makes them effective as a competitive moat, and what makes them dangerous as a strategic liability. In 2026, enterprise software buyers are acquiring switching costs from four separate AI vendors simultaneously — Microsoft, Salesforce, ServiceNow, and Amazon Web Services — and almost none of them have a methodology for measuring what that accumulation means for their negotiating position in 2028.
This is not a complaint about vendor lock-in in the abstract. It is a structural observation about how AI adoption creates dependencies at a speed and depth that prior software waves did not. The ERP wave of the 1990s and early 2000s created large switching costs, but those costs were visible — migration projects took years, carried defined price tags, and required explicit board approval. The current AI wave is embedding switching costs in data pipelines, workflow automations, employee habit formation, and institutional knowledge — none of which show up on a balance sheet.
The Seven Powers Framework Applied to Enterprise AI
Hamilton Helmer’s framework for sustainable competitive advantage identifies switching costs as one of seven durable sources of power. The definition is precise: switching costs exist when the value lost by a customer switching to a competitor exceeds the potential gain from the switch. The critical word is lost. Switching costs are not merely the direct financial cost of migration. They include lost productivity during transition, retraining costs, the loss of customised configurations, and the institutional knowledge embedded in the current system.
Applied to enterprise AI in 2026, the framework reveals something that has not been widely articulated: the AI vendors are not competing on the same dimension as enterprise buyers are evaluating them. Buyers are running capability evaluations — which model produces better outputs, which interface is easier for employees to use, which API has lower latency. Vendors are running switching-cost accumulation campaigns. The two processes are not aligned, and buyers are losing ground in the negotiation before the negotiation begins.
Microsoft’s Copilot strategy is the clearest example. As of Microsoft’s fiscal Q3 2026 earnings, Copilot penetration within Microsoft 365 enterprise customers stood at approximately 3.3 percent — a number that received significant analyst attention as evidence that the AI wave had stalled. But the penetration figure misses what is actually happening. The 3.3 percent of seats that are using Copilot are not generating revenue proportional to the product’s value; they are generating workflow dependencies. Every enterprise user who builds a regular Copilot prompt workflow for meeting summaries, email drafting, or document analysis is creating a behavioural switching cost that does not exist in a spreadsheet. Microsoft’s own Work Trend Index research documents the productivity patterns that users adopt within 90 days of Copilot activation — and the research, while designed to demonstrate ROI, also inadvertently documents the depth of workflow integration that would need to be unwound for a user to switch to an alternative.
Four Simultaneous Accumulation Paths
What distinguishes 2026 from prior technology waves is the simultaneous accumulation of switching costs across multiple vendor relationships. A mid-market enterprise with a standard technology stack is now likely building AI dependencies with at least four separate vendors at once.
Microsoft Copilot. Embedded in Microsoft 365, Teams, and GitHub. Switching costs accumulate through employee habit formation, Copilot Studio workflow automations built on top of SharePoint and Teams data, and the institutional knowledge encoded in customised Copilot agents. The relevant switching cost is not the Microsoft licence fee. It is the cost of rebuilding custom agents, retraining employees, and migrating the underlying data connections.
Salesforce Agentforce. Embedded in the CRM layer, where customer data, deal history, and service records already live. Agentforce switching costs are among the highest in the current wave because they compound on top of existing Salesforce CRM switching costs. An enterprise that switches away from Agentforce is implicitly evaluating a simultaneous CRM migration — a project that typically runs 18 to 36 months and carries a failure rate that most CFOs will not accept.
ServiceNow AI. Embedded in the IT service management layer. ServiceNow’s AI capabilities, launched in 2025, are tied to the ITSM workflow engine that most large enterprises have spent years configuring. The switching cost here is the highest of the four: ServiceNow configurations represent tens of thousands of engineering hours at most enterprise customers, and AI capabilities are being layered into those configurations directly, making them inseparable from the underlying workflow logic.
AWS Bedrock. Embedded in the infrastructure layer. Bedrock is the AI platform most likely to be invisible to business stakeholders — it is the runtime environment where developers are building internal AI applications. The switching cost is developer familiarity with Bedrock APIs, the cost of refactoring applications built on Bedrock-specific abstractions, and the inertia created by the integration of Bedrock with existing AWS infrastructure (IAM policies, VPC configurations, S3 data lakes). AWS infrastructure switching costs are the most studied and best understood of the four, but Bedrock adds a new layer that was not present in prior AWS lock-in analyses.
The critical observation is not that any one of these switching costs is unusual. It is that all four are accumulating simultaneously, in the same organisation, across different departments, on different timelines, with different stakeholders — and with no one in the organisation responsible for measuring the aggregate.
The Accountability Gap Nobody Is Naming
Here is what the power structure looks like from the vendor side. Microsoft, Salesforce, ServiceNow, and AWS are each running a strategy that is rational from their individual perspective: embed AI capabilities as deeply as possible into products that the enterprise already depends on, make the AI capabilities essential to daily workflows before the enterprise has time to conduct a structured evaluation, and ensure that the switching cost of removing the AI capability is higher than the switching cost of the underlying product alone.
From the enterprise buyer’s perspective, this strategy is not visible as a coordinated dynamic. Each purchase decision is evaluated individually: should we expand Copilot seats, should we activate Agentforce, should we deploy ServiceNow AI for our help desk? The evaluation criteria are capability-based. The switching cost accumulation is a byproduct, not a line item.
This is a documented pattern in enterprise software procurement. It appeared in the transition from on-premise to cloud software in the 2010s, where enterprises made individual cloud migration decisions that collectively created multi-vendor dependencies without any individual decision appearing to carry significant lock-in risk. The AI wave is repeating the pattern at higher speed because AI capabilities are embedded directly into existing products rather than requiring separate procurement decisions.
The accountability gap is in the governance structure. Most enterprise procurement functions evaluate AI vendors on capability, price, and security posture. Very few have a formal methodology for measuring switching cost accumulation as a risk variable. The closest approximation is vendor concentration risk analysis, which large financial institutions apply to their technology vendors — but vendor concentration risk analysis was designed for single-vendor dependency, not for the simultaneous multi-vendor switching cost accumulation that is now occurring.
The jobs-to-be-done failure pattern in enterprise AI adoption documents a related problem: AI tools are being hired for the wrong job by enterprise buyers, leading to low utilisation rates. But low utilisation does not mean low lock-in. An enterprise can have 3 percent Copilot utilisation and still have 60 percent of its knowledge workers with Copilot habits embedded in their daily workflow — the remaining 97 percent of seats represent potential utilisation growth that is contractually priced in, while the switching cost accumulates in the 3 percent who are already active.
What the Historical Record Shows About Multi-Vendor Lock-In
The closest historical parallel to the current situation is the enterprise middleware market of the late 1990s and early 2000s. Enterprises were simultaneously deploying Oracle databases, SAP ERP, Siebel CRM, and IBM middleware — each of which carried significant switching costs individually, and which collectively created an enterprise IT architecture that was expensive to change at the component level because changing any one component required recertifying the integration with all others.
The middleware analogy is imperfect but instructive. The key difference is integration coupling. In the middleware era, enterprise software components were loosely coupled by modern standards — they communicated through defined APIs and data formats, and the integration layer was visible as a discrete cost center. In the AI era, the integration is happening at the data layer: AI capabilities ingest enterprise data, learn from enterprise workflows, and embed institutional knowledge in ways that are not separated from the underlying product. When a knowledge worker’s Copilot custom agent ingests 18 months of internal meeting transcripts and email history to generate context-aware summaries, the resulting institutional knowledge is encoded in Microsoft’s infrastructure, not in a portable format that migrates cleanly to an alternative.
The middleware wave eventually broke the multi-vendor lock-in through standardisation — XML, SOAP, and later REST APIs created interoperability layers that reduced switching costs at the integration seam. Whether a comparable standardisation layer will emerge in AI is an open question. The current trajectory suggests it will not emerge quickly: Microsoft, Salesforce, and ServiceNow have economic incentives to prevent interoperability at the AI layer, and the technical architecture of large language model fine-tuning and retrieval-augmented generation does not naturally produce portable outputs.
The Measurement Problem
Switching costs are hard to measure precisely because their magnitude depends on circumstances that have not yet occurred. You cannot know exactly what it would cost to migrate off Salesforce until you are attempting the migration. But that uncertainty is not a reason to avoid measurement — it is a reason to measure conservatively and early, before the switching cost accumulates further.
A practical measurement approach for enterprise AI switching costs would have four components.
Data residency audit. For each AI product, document what enterprise data has been ingested into vendor infrastructure, in what format, and whether it is exportable in a portable format. This is the most underperformed due diligence task in enterprise AI procurement. Most vendor contracts specify data portability rights in broad terms that have never been tested against a real migration scenario.
Workflow dependency mapping. Identify which business processes have been modified to depend on AI outputs. A meeting summary workflow that previously produced a human-written summary and now produces a Copilot summary is a workflow dependency — removing Copilot requires either restoring the human workflow or replacing the AI output with an alternative. The cost of that substitution is the switching cost of the workflow dependency.
Custom configuration inventory. For products like Salesforce Agentforce and ServiceNow AI, document the custom configurations, custom agents, and custom training data that have been created within the vendor’s environment. This is the switching cost that is most often underestimated: the configuration work is not billable as a line item, it accumulates through internal engineering effort, and it is rarely documented comprehensively until a migration is imminent.
Employee competency assessment. Measure how deeply employee workflows depend on specific AI tools. This is the switching cost that is most often ignored entirely, because enterprise IT governance does not typically include employee habit formation as a procurement risk variable. But employee retraining costs — the time required for knowledge workers to achieve equivalent productivity with a different AI tool — are a real and measurable switching cost that should be estimated before it accumulates.
The Counterargument: Competition Will Limit Switching Costs
The obvious counterargument is that the AI market is intensely competitive, and competition will prevent switching costs from becoming prohibitive. If Microsoft raises Copilot prices aggressively, enterprises will migrate to Google Workspace AI or another alternative, and the threat of that migration will constrain Microsoft’s pricing power.
This argument has historical precedent in the enterprise software market. Oracle’s database pricing power has been constrained by the existence of PostgreSQL and other alternatives, even though Oracle database switching costs are high. Salesforce’s pricing power has been constrained by Microsoft Dynamics and HubSpot, even though Salesforce CRM switching costs are among the highest in enterprise software.
The argument is valid as far as it goes, but it understates the current dynamic in two ways. First, the competitive pressure on AI pricing requires that competitive alternatives exist at equivalent capability levels — and in 2026, the capability gap between leading enterprise AI products (Copilot, Agentforce, Bedrock) and their nearest alternatives is larger than the capability gap between Oracle and PostgreSQL databases was at the peak of Oracle’s lock-in. Second, the switching costs in the current wave compound across vendors in a way that prior waves did not: an enterprise switching off Copilot must also evaluate the downstream effects on its Agentforce and Bedrock integrations, because those integrations may depend on data flows that pass through Microsoft infrastructure.
A more accurate framing of the competitive constraint argument is: competition will prevent extreme price increases, but it will not prevent moderate and sustained price increases that remain below the switching cost threshold. That threshold is higher than most enterprise buyers currently estimate, and it is growing.
What Enterprises Should Do Before 2027
The switching cost accumulation problem does not have a clean solution, because the accumulation is a byproduct of genuine product value. Enterprises are using Copilot, Agentforce, and Bedrock because those products are producing real outputs, and stopping or slowing adoption to limit switching cost accumulation would impose a direct productivity cost that is easier to measure than the future switching cost risk.
The practical prescription is measurement and architecture discipline, not adoption restraint.
Enterprises that build AI capabilities on top of abstraction layers — model-agnostic APIs, standardised data formats, documented integration contracts — will have lower switching costs than enterprises that build directly on vendor-specific APIs and vendor-specific data pipelines. This is not a new principle; it is the same principle that drove enterprise adoption of ESB (enterprise service bus) architectures in the 2000s. The application to AI is straightforward: treat AI vendor APIs as integration points that need abstraction, not as native application layers.
The broader enterprise AI ROI reckoning is already visible in the data: enterprises that deployed AI broadly without measurement frameworks cannot demonstrate returns, while enterprises that deployed narrowly with clear job-to-be-done definitions can. The switching cost dimension adds a second measurement requirement: enterprises that deploy AI without tracking the depth of vendor dependency will face a second reckoning in 2027 and 2028 when the switching costs they accumulated in 2025 and 2026 determine their negotiating position in contract renewals.
The enterprises that will navigate this best are those that treat AI vendor relationships the way sophisticated buyers treat any supplier relationship where switching costs are high: with explicit documentation of dependency, regular competitive benchmarking, and contractual provisions that maintain the option to switch even when the probability of switching is low. The option value of being able to switch is worth preserving even when you do not intend to exercise it. In the current market, most enterprises are allowing that option to expire unnoticed.
Frequently Asked Questions
What are AI vendor switching costs and why do they matter in 2026?
AI vendor switching costs are the total costs — direct migration expenses, productivity loss during transition, retraining costs, and the value of lost institutional knowledge — that an enterprise would incur if it replaced a deployed AI system with a competing alternative. They matter in 2026 because enterprises are simultaneously deploying AI systems from multiple vendors (Microsoft, Salesforce, ServiceNow, AWS) and accumulating switching costs across all of them before developing a methodology for measuring the aggregate exposure.
How do Microsoft Copilot switching costs differ from traditional software switching costs?
Traditional software switching costs are primarily data migration and retraining costs. Microsoft Copilot creates an additional switching cost category: institutional knowledge encoded in AI-generated outputs and custom agents. When employees build Copilot workflows that ingest months of organisational communication history, that context is stored in Microsoft’s infrastructure. Migrating to an alternative AI system would require rebuilding that context, which cannot be accomplished through a data migration alone.
Can competition in the AI market limit enterprise vendor lock-in?
Competition constrains extreme pricing power but does not eliminate switching cost leverage. Competing alternatives must reach capability parity before competitive pressure becomes effective, and in 2026, the capability gap between leading enterprise AI products and their nearest alternatives is significant. More importantly, switching costs compound across vendors when integrations depend on shared data flows — switching off one vendor may require evaluating downstream effects on other vendor integrations.
What is the most underestimated enterprise AI switching cost?
Custom configuration and agent development within vendor-managed environments. Enterprises building Salesforce Agentforce agents, ServiceNow AI workflows, and Microsoft Copilot Studio automations are encoding institutional knowledge in configurations that are not portable outside the vendor’s platform. This work accumulates through internal engineering effort and is rarely documented comprehensively until a migration is attempted.
How should enterprises measure AI vendor switching costs before they accumulate?
Four components: a data residency audit (what enterprise data lives in vendor infrastructure, in what format, how portable), a workflow dependency map (which business processes have been modified to depend on AI outputs), a custom configuration inventory (documented count and complexity of vendor-specific configurations), and an employee competency assessment (how deeply employee workflows depend on specific AI tools, and the estimated retraining cost of substituting an alternative).
Sources: Hamilton Helmer, 7 Powers: The Foundations of Business Strategy; Microsoft Fiscal Q3 2026 Earnings Call (April 2026); Salesforce Q1 FY2027 Earnings Presentation (May 2026); ServiceNow Q1 2026 Investor Day Materials; Gartner Cloud Strategy Research 2026; Harvard Business Review — Technology Strategy 2026; IDC Enterprise AI Adoption Survey, Q1 2026 (NOT YET SOURCED — verify against IDC 2026 publication).
