A manufacturing company brought me in to evaluate why they couldn’t move off a vendor’s AI platform even though the economics no longer made sense. They’d started with the vendor five years ago, when the alternative landscape was narrower. Now the alternatives were cheaper and faster. But the transition cost analysis came back at $8M and 18 months. They stayed.

This happens more often than enterprises admit. Not because the new vendor is actually worse. But because switching has hard costs that don’t show up in ROI calculators until you’re 12 months in.

The standard analysis of vendor switching looks straightforward: new contract costs, tool retraining, migration of existing models. Most enterprises estimate weeks or months and set a budget. Then they start the transition and find that the switching cost was 3x what they estimated.

The gap isn’t a calculation error. It’s that switching costs have hidden layers that only surface once you commit.

What Shows Up in the Budget

When you plan to switch from Vendor A to Vendor B, you typically account for: – License costs for the new platform – Data migration—moving existing datasets, models, configurations – Retraining staff on new interfaces and workflows – Time for parallel running during transition

A responsible team will also budget for: – Regression testing (making sure the new platform produces similar results) – Performance benchmarking (validating that latency, throughput match the old system) – Integration work (connecting the new platform to downstream systems)

These are real costs. Most enterprises estimate them conservatively. Then they hit the switching costs that don’t appear on spreadsheets.

What Doesn’t Show Up Until You Start

First: architectural dependencies. You didn’t think the old vendor was deeply integrated into your architecture, but it turns out you have 47 downstream systems that make assumptions about how the old vendor’s API works, how it handles errors, how data flows. The new vendor’s API is functionally equivalent but architecturally different. You need to re-abstract two layers of code.

Second: data format translation. Your old vendor had a specific way of representing model outputs, uncertainty, feature importance. The new vendor uses different representations. The systems consuming that output were built assuming the old format. Updating them means re-testing each one, because slight format changes can have disproportionate effects downstream.

Third: performance characteristics. The old system was slow but predictable. The new system is fast but bursty. Your rate-limiting, queuing, and caching logic was built for the old characteristics. The new vendor’s system hits your bottlenecks differently.

Fourth: failure modes. The systems around your AI infrastructure were built to handle specific failure modes from Vendor A. When Vendor B fails, it fails differently. You discover this six months into production when something unexpected happens.

Fifth: organizational knowledge. The team that built the first system understood Vendor A’s quirks, optimizations, gotchas. They’ve optimized for Vendor A in ways that are obvious once you live with it and mysterious if you’re coming from outside. When you switch, you lose that accumulated knowledge. The new team has to learn Vendor B’s quirks from scratch.

The Hidden Cost Structure

These costs don’t distribute evenly. Some are concentrated at the decision point (data migration), but others are spread across months of steady work (re-abstraction, re-testing, knowledge transfer). This spreading makes them easy to underestimate. If someone asks “how long will migration take?” and the answer is “one engineer for two weeks,” that’s easy to estimate. If the answer is “various engineers will spend 30% of their time on vendor-specific integration work for nine months,” that’s much harder to quantify and easy to underestimate.

The switching cost also compounds with the vendor’s own evolution. While you’re transitioning to Vendor B, Vendor A is still being used by other teams and is still evolving. The longer the transition takes, the wider the gap between what you’re leaving behind and what you’re transitioning from. You might end up re-building transition logic three times because Vendor A changed mid-transition.

Why This Matters for Procurement

When you’re evaluating a new AI platform, the vendor will tell you that switching costs are low. They’ll show you case studies of companies that moved in 90 days. Some of those companies were probably moving from something worse, or they had simpler architectures, or they had teams with free capacity. Those stories aren’t wrong. They’re just not predictive of your situation.

The real switching cost depends on: – How integrated your current vendor is into your architecture – How many systems depend on the specific output format, error handling, latency profile of your current vendor – How much accumulated optimization and knowledge your team has developed around the current vendor – Whether you have excess engineering capacity to absorb the transition – What your tolerance is for parallel-running both systems during the switch

Most enterprises underestimate this because they think about switching cost as migration logistics, not as architectural debt. If your current vendor is deeply integrated and your systems are optimized around its specific characteristics, switching is expensive even if the new vendor is technically superior.

How to Actually Estimate It

Start by mapping integration points. Where does your current vendor connect to other systems? What assumptions do those systems make about the vendor’s behavior? For each assumption, decide: does the new vendor meet it, or do we need to re-abstract?

Model the slowest piece of your transition. It’s rarely data migration. It’s usually the re-abstraction and integration work, or the regression testing of systems you forgot existed. Assume that piece will take 30% longer than your first estimate.

Identify what knowledge will be lost. It’s not just “how to use the interface.” It’s “we’ve learned that this vendor performs poorly if you batch requests larger than X, so we built a pre-processing step.” The new vendor might not have that problem, but you might rebuild the pre-processing step anyway because it seems safer.

Factor in parallel running costs. Most transitions run both systems for months. That’s twice the infrastructure, twice the monitoring, twice the data pipeline work. It takes longer than you think to reach confidence.

The Practical Implication

This doesn’t mean you should never switch. It means you should estimate the true switching cost and be realistic about whether the new vendor’s advantages actually exceed it. Switching costs vary significantly based on architecture decisions — this applies to any platform relationship. Sometimes the new vendor’s advantages exceed the cost. Sometimes the switching cost is so high that you’re better off optimizing within the current vendor’s constraints.

The enterprises that get this right are usually the ones that think about switching cost during vendor selection, not during the transition. They ask: “if we needed to move off this vendor in three years, how hard would it be?” If the answer is very hard, they either negotiate better terms with the current vendor or choose a different one.

The cost of switching isn’t primarily about logistics. It’s about how deeply integrated the vendor has become with your architecture and operations. The deeper the integration, the higher the cost. And most enterprises don’t realize how deep the integration goes until they try to leave.