Skip to main content

Most Enterprises Think They Can Switch AI Vendors in a Month ... Most Who've Tried Couldn't

Emily Mabie
Zapier

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on."

Most enterprise leaders don't expect that to be the experience.

A recent Zapier survey of 500 US enterprise C-suite executives and decision-makers asked leaders how fast they could move from their primary AI vendor to a different one. 89% said they could complete the switch within four weeks. 41% said two to five business days. 13% said they could do it in a single day.

Two-thirds of leaders said their organization had already attempted a migration between AI platforms. Among that group, only 42% reported a smooth transition. The remaining 58% said the migration either failed or took significantly more effort than expected.

That's not a small gap. That's a planning failure waiting to happen.

Why the Math Doesn't Work

Switching a vendor sounds like changing a setting. In practice it's closer to retrofitting a building. By the time a team is migrating, the AI has been wired into a long list of things nobody planned to count: prompts that someone tuned over weeks, downstream systems that expect a specific output format, an internal tool that depends on a feature only one model supports, retrieval pipelines sized for a particular context window, monitoring that quietly assumes a particular response time.

None of that is in the contract. None of it is in the original adoption plan. Most of it isn't documented at all. It accumulates because that's what happens when a tool gets useful and people build on it.

The four-week estimate assumes a clean swap of one model for another. The actual job is finding everything that depends on the old one and deciding, piece by piece, what to do about it. That's a systems problem, and procurement isn't equipped to solve it on its own.

What the Rest of the Data Is Saying

The same survey shows enterprises starting to see the problem. 81% of leaders say they're at least a little concerned about their organization's dependency on specific AI vendors. 29% say they're very concerned. The two top concerns, tied at 46%, are data migration challenges and overdependence on a single vendor. Limited flexibility to integrate AI with existing tools comes in at 42%.

Almost half of organizations (47%) now have a dedicated internal team evaluating and managing AI vendors. 44% use multiple vendors at the same time to spread risk. 34% are deliberately designing around data portability and standard APIs. A third are using third-party orchestration to coordinate AI workflows across systems. These are all variations of the same instinct: keep the option to change your mind.

What strikes me about that list is how operational it is. Five years ago, vendor risk was mostly a procurement conversation. Today it's an architecture conversation, an integration conversation, and increasingly an observability conversation. The teams doing this well are treating AI vendor flexibility as a property of their systems, not a clause in a contract.

The Observability Piece Nobody Is Talking About

If you can't see what your AI is doing today, you can't tell what would break if it disappeared.

That sounds obvious, but it's the part of the migration problem that most often gets skipped. Teams have logs of API calls. They have cost dashboards. What they often don't have is a clear picture of which workflows depend on which model, what those workflows actually expect from the model's output, and which of those expectations are load-bearing versus incidental.

When that visibility is missing, every migration starts with discovery. People build a list of integrations from memory. Something gets missed. A scheduled job runs three weeks later and quietly produces wrong output, because the new model phrases things slightly differently and the parser downstream expects the old phrasing.

The teams that migrate well have done this work in advance. They can show, on demand, where AI is in their stack, what each call is doing, what the expected output looks like, and what depends on it. That's an inventory plus a behavioral baseline, and most organizations don't have either.

What "Designing for Change" Actually Looks Like

A few patterns hold up.

Treat the AI model as a replaceable component. Workflows should be structured so the model is one step in a longer process, with clear inputs and clear outputs that other systems agree on. When the contract between systems lives outside the model, swapping the model gets easier.

Keep your data portable from day one. The survey lists data migration as the single biggest concern, and the teams who handle it best aren't pulling their data out at migration time. They've kept it in their own systems all along, with the vendor processing it rather than owning it.

Run more than one vendor on purpose. The 44% using multiple vendors aren't doing it because they can't decide. They're doing it because routing different workloads to different providers builds the operational muscle for switching. The first migration is hard. The fifth is routine.

Watch the outputs. API call volume tells you how often a model gets used. It doesn't tell you whether the answers it produces are still good, drifting, or quietly degrading. The organizations that catch a vendor's quality slipping early are the ones with output-level monitoring in place before they need it.

Where This Leaves Things

Almost three-quarters of enterprise leaders say losing their primary AI vendor would either disrupt operations or stop key business functions outright. That dependency will keep deepening. The leaders taking it seriously aren't trying to avoid lock-in by avoiding adoption. They're embedding AI deeply, and building the surrounding systems so that the model itself stays optional.

That's a longer planning horizon than four weeks. It's also the only version of the work that actually holds up when a migration arrives.

Emily Mabie is AI Automation Engineer at Zapier

Hot Topics

The Latest

Enterprises today operate in a real-time environment where uninterrupted access to trusted data has become a baseline expectation for users, applications and automated systems. Traditional DataOps models, built on manual effort and human triage, cannot keep pace with this always active demand. AI agents are emerging as the operational backbone, ensuring consistent data availability, reinforcing trustworthiness and enabling a level of scale that manual processes cannot achieve ...

For decades, trust in the digital workplace rested on familiar signals. We trusted faces on video calls, voices on the phone, and emails that appeared to come from people we knew. These cues felt human and intuitive. They anchored how decisions were made, approvals were granted, and access was authorized. AI-powered deepfakes have quietly broken that model ...

Cloud migration was supposed to be a one-way door. For most enterprises, it turns out it isn't. Cloud data repatriation is a real and growing trend. A new survey ... finds that 89% of organizations plan to expand their on-premises infrastructure footprint over the next two years — and 75% have already moved at least some workloads back from public cloud in the past 24 months. The findings point to a broad rethinking of where data belongs ...

Over the past few years, large language models (LLMs) have revolutionized the software industry. Given their ability to excel at multi-step reasoning, LLMs have helped enterprises streamline workflows and adapt to the unknown. However, employing such models comes with sky-high costs, latency issues, and limited flexibility. In the realm of IT operations, it is generally wiser to employ smaller, domain-specific models instead ...

For years, DevOps teams operated under a simple assumption: collect enough telemetry, and you can find and fix any problem. That assumption is breaking down. Modern enterprises now operate across microservices, hybrid cloud environments, APIs, Kubernetes, and highly automated delivery pipelines. Releases happen continuously, dependencies shift constantly, and failures spread faster than teams can diagnose them ...

New Relic surveyed IT and engineering leaders from the media and entertainment (M&E) sector to understand what's working — and where challenges persist with their observability practices. The findings reveal how M&E organizations are navigating rising platform complexity, audience expectations, and AI-driven change. Below are five takeaways that stand out ...

Let me start with something I've seen play out more times than I can count. A team hits a wall with the cloud. Costs creep up, then spike. Performance starts to feel inconsistent. Someone in finance asks a simple question like "why did this double?" and nobody has a clean answer ... Maybe this isn't the right place for everything. That realization feels like a breakthrough, like you've identified the problem. In reality, you've just identified the starting line ...

In MEAN TIME TO INSIGHT Episode 24, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses network observability tool sprawl ... 

In cloud-native systems, scaling is often as simple as moving a slider. For on-premise databases, the stakes are different. Over-provisioning hardware is expensive. Under-provisioning leads to performance bottlenecks that are difficult to fix once the equipment is in the rack ...

When most people think about cybersecurity, they picture firewalls, encryption, and access controls — technical tools designed to protect systems and data. But beneath the technology lies a deeper set of principles about trust, decision-making, and resilience ... The best leaders don't eliminate risk. They manage it intelligently. And in many ways, cybersecurity offers a surprisingly useful playbook for doing exactly that ...

Most Enterprises Think They Can Switch AI Vendors in a Month ... Most Who've Tried Couldn't

Emily Mabie
Zapier

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on."

Most enterprise leaders don't expect that to be the experience.

A recent Zapier survey of 500 US enterprise C-suite executives and decision-makers asked leaders how fast they could move from their primary AI vendor to a different one. 89% said they could complete the switch within four weeks. 41% said two to five business days. 13% said they could do it in a single day.

Two-thirds of leaders said their organization had already attempted a migration between AI platforms. Among that group, only 42% reported a smooth transition. The remaining 58% said the migration either failed or took significantly more effort than expected.

That's not a small gap. That's a planning failure waiting to happen.

Why the Math Doesn't Work

Switching a vendor sounds like changing a setting. In practice it's closer to retrofitting a building. By the time a team is migrating, the AI has been wired into a long list of things nobody planned to count: prompts that someone tuned over weeks, downstream systems that expect a specific output format, an internal tool that depends on a feature only one model supports, retrieval pipelines sized for a particular context window, monitoring that quietly assumes a particular response time.

None of that is in the contract. None of it is in the original adoption plan. Most of it isn't documented at all. It accumulates because that's what happens when a tool gets useful and people build on it.

The four-week estimate assumes a clean swap of one model for another. The actual job is finding everything that depends on the old one and deciding, piece by piece, what to do about it. That's a systems problem, and procurement isn't equipped to solve it on its own.

What the Rest of the Data Is Saying

The same survey shows enterprises starting to see the problem. 81% of leaders say they're at least a little concerned about their organization's dependency on specific AI vendors. 29% say they're very concerned. The two top concerns, tied at 46%, are data migration challenges and overdependence on a single vendor. Limited flexibility to integrate AI with existing tools comes in at 42%.

Almost half of organizations (47%) now have a dedicated internal team evaluating and managing AI vendors. 44% use multiple vendors at the same time to spread risk. 34% are deliberately designing around data portability and standard APIs. A third are using third-party orchestration to coordinate AI workflows across systems. These are all variations of the same instinct: keep the option to change your mind.

What strikes me about that list is how operational it is. Five years ago, vendor risk was mostly a procurement conversation. Today it's an architecture conversation, an integration conversation, and increasingly an observability conversation. The teams doing this well are treating AI vendor flexibility as a property of their systems, not a clause in a contract.

The Observability Piece Nobody Is Talking About

If you can't see what your AI is doing today, you can't tell what would break if it disappeared.

That sounds obvious, but it's the part of the migration problem that most often gets skipped. Teams have logs of API calls. They have cost dashboards. What they often don't have is a clear picture of which workflows depend on which model, what those workflows actually expect from the model's output, and which of those expectations are load-bearing versus incidental.

When that visibility is missing, every migration starts with discovery. People build a list of integrations from memory. Something gets missed. A scheduled job runs three weeks later and quietly produces wrong output, because the new model phrases things slightly differently and the parser downstream expects the old phrasing.

The teams that migrate well have done this work in advance. They can show, on demand, where AI is in their stack, what each call is doing, what the expected output looks like, and what depends on it. That's an inventory plus a behavioral baseline, and most organizations don't have either.

What "Designing for Change" Actually Looks Like

A few patterns hold up.

Treat the AI model as a replaceable component. Workflows should be structured so the model is one step in a longer process, with clear inputs and clear outputs that other systems agree on. When the contract between systems lives outside the model, swapping the model gets easier.

Keep your data portable from day one. The survey lists data migration as the single biggest concern, and the teams who handle it best aren't pulling their data out at migration time. They've kept it in their own systems all along, with the vendor processing it rather than owning it.

Run more than one vendor on purpose. The 44% using multiple vendors aren't doing it because they can't decide. They're doing it because routing different workloads to different providers builds the operational muscle for switching. The first migration is hard. The fifth is routine.

Watch the outputs. API call volume tells you how often a model gets used. It doesn't tell you whether the answers it produces are still good, drifting, or quietly degrading. The organizations that catch a vendor's quality slipping early are the ones with output-level monitoring in place before they need it.

Where This Leaves Things

Almost three-quarters of enterprise leaders say losing their primary AI vendor would either disrupt operations or stop key business functions outright. That dependency will keep deepening. The leaders taking it seriously aren't trying to avoid lock-in by avoiding adoption. They're embedding AI deeply, and building the surrounding systems so that the model itself stays optional.

That's a longer planning horizon than four weeks. It's also the only version of the work that actually holds up when a migration arrives.

Emily Mabie is AI Automation Engineer at Zapier

Hot Topics

The Latest

Enterprises today operate in a real-time environment where uninterrupted access to trusted data has become a baseline expectation for users, applications and automated systems. Traditional DataOps models, built on manual effort and human triage, cannot keep pace with this always active demand. AI agents are emerging as the operational backbone, ensuring consistent data availability, reinforcing trustworthiness and enabling a level of scale that manual processes cannot achieve ...

For decades, trust in the digital workplace rested on familiar signals. We trusted faces on video calls, voices on the phone, and emails that appeared to come from people we knew. These cues felt human and intuitive. They anchored how decisions were made, approvals were granted, and access was authorized. AI-powered deepfakes have quietly broken that model ...

Cloud migration was supposed to be a one-way door. For most enterprises, it turns out it isn't. Cloud data repatriation is a real and growing trend. A new survey ... finds that 89% of organizations plan to expand their on-premises infrastructure footprint over the next two years — and 75% have already moved at least some workloads back from public cloud in the past 24 months. The findings point to a broad rethinking of where data belongs ...

Over the past few years, large language models (LLMs) have revolutionized the software industry. Given their ability to excel at multi-step reasoning, LLMs have helped enterprises streamline workflows and adapt to the unknown. However, employing such models comes with sky-high costs, latency issues, and limited flexibility. In the realm of IT operations, it is generally wiser to employ smaller, domain-specific models instead ...

For years, DevOps teams operated under a simple assumption: collect enough telemetry, and you can find and fix any problem. That assumption is breaking down. Modern enterprises now operate across microservices, hybrid cloud environments, APIs, Kubernetes, and highly automated delivery pipelines. Releases happen continuously, dependencies shift constantly, and failures spread faster than teams can diagnose them ...

New Relic surveyed IT and engineering leaders from the media and entertainment (M&E) sector to understand what's working — and where challenges persist with their observability practices. The findings reveal how M&E organizations are navigating rising platform complexity, audience expectations, and AI-driven change. Below are five takeaways that stand out ...

Let me start with something I've seen play out more times than I can count. A team hits a wall with the cloud. Costs creep up, then spike. Performance starts to feel inconsistent. Someone in finance asks a simple question like "why did this double?" and nobody has a clean answer ... Maybe this isn't the right place for everything. That realization feels like a breakthrough, like you've identified the problem. In reality, you've just identified the starting line ...

In MEAN TIME TO INSIGHT Episode 24, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses network observability tool sprawl ... 

In cloud-native systems, scaling is often as simple as moving a slider. For on-premise databases, the stakes are different. Over-provisioning hardware is expensive. Under-provisioning leads to performance bottlenecks that are difficult to fix once the equipment is in the rack ...

When most people think about cybersecurity, they picture firewalls, encryption, and access controls — technical tools designed to protect systems and data. But beneath the technology lies a deeper set of principles about trust, decision-making, and resilience ... The best leaders don't eliminate risk. They manage it intelligently. And in many ways, cybersecurity offers a surprisingly useful playbook for doing exactly that ...