There's a version of the CRM conversation that doesn't start with "our reps aren't logging calls." It starts with something more sophisticated: "We've invested heavily in our current setup. We have integrations with our billing system, our marketing automation, our support platform, our data warehouse. Switching would be enormously disruptive. So let's focus on optimising what we have."

This is a reasonable position. It's also, frequently, a way of avoiding a harder conversation.

Integration complexity is the single most effective reason organisations give for tolerating a CRM that isn't delivering value. It's not wrong — integration costs are real, migration risk is real, business disruption is real. But "we have a lot of integrations" and "those integrations justify the status quo" are two different claims, and they're often conflated in ways that lead organisations to spend years optimising around a problem instead of fixing it.

Here's a framework for separating the two.

First: Audit What Your Integrations Actually Do

Most organisations, when pressed, can't answer this question cleanly: what does each CRM integration actually deliver, and what would break if it weren't there?

Before any conversation about whether to stay, switch, or rebuild, you need an honest integration inventory. Not just a list of what's connected — but what each connection does, how often it's used, who depends on it, and what the cost of rebuilding it would actually be on a different platform.

When organisations do this exercise rigorously, they typically find their integrations fall into three categories:

Category 1 — Load-bearing integrationsThese are genuinely complex and genuinely critical. Bi-directional sync with your ERP or billing system. Revenue recognition logic that touches deal close data. Territory and quota management that feeds compensation calculations. Customer health scores that flow from support into pipeline. If these break, real business processes break with them. These are legitimate switching costs and deserve serious weight in any evaluation.

Category 2 — Convenience integrationsThese exist because someone built them, not because they're irreplaceable. A Zapier automation that creates a Slack message when a deal closes. A dashboard that pulls pipeline data into a Google Sheet for a weekly report. A one-way sync that pushes contact data to a marketing list. These have real value and would take time to rebuild, but they're not blocking anything mission-critical. Most modern CRM platforms have native equivalents or straightforward migration paths.

Category 3 — Ghost integrationsThese were built for a use case that no longer exists. An integration with a tool you stopped using. A sync that was set up for a reporting requirement that changed two years ago. A webhook that fires but nobody's sure what it does. In every CRM audit we've seen, at least 20–30% of integrations fall into this category. They contribute to the switching cost calculation on paper but have no actual operational value.

When you separate these three categories, the integration complexity argument usually looks different. The load-bearing integrations are real costs — but they're also the ones that are most likely to have well-trodden migration paths, because every CRM vendor knows they have to handle them to win enterprise deals.

The Optimisation Question You Should Ask First

Before the switching conversation, there's a prior question that deserves an honest answer: are your integrations actually working correctly, or have you just stopped noticing the gaps?

Integration quality degrades over time. APIs change. Data schemas evolve. The sync that worked cleanly in 2021 may be dropping records, creating duplicates, or propagating stale data in ways that have become invisible because everyone has adapted their behavior around the problem. Reps have learned to check the source system rather than trust the CRM. Finance reconciles manually because the sync isn't reliable. RevOps has built a spreadsheet to catch what the integration misses.

This is a meaningful cost that rarely appears in the switching cost calculation, because it's embedded in people's daily routines rather than showing up as a line item. If your current integration landscape requires workarounds to function — and most do — the real baseline isn't "working system" but "partially working system with human duct tape."

When Staying and Fixing Is the Right Answer

Let's be direct: there are genuine situations where the integration complexity justifies staying and investing in improvement rather than switching. This isn't always an excuse — sometimes it's the correct analysis.

You should stay and fix if your load-bearing integrations are genuinely complex and proprietary — where you've built custom logic that reflects your specific business model and would take 12+ months to rebuild equivalently elsewhere. You should stay and fix if your team has deep institutional knowledge of the current system architecture that would be costly to replace. You should stay and fix if you're within 18 months of a major business event — an acquisition, a product launch, a market expansion — where CRM disruption would be particularly costly.

But staying and fixing means actually fixing, not continuing to optimise around the edges. It means a real configuration and adoption project with executive sponsorship, defined success metrics, and a timeline. "Stay and fix" as a strategy is only legitimate if you can answer: fix what, by when, measured how?

The Diagnostic: Integration Inventory Framework

◆ Integration Audit — Four Questions

1. List every CRM integration. For each one: what business process does it support, and what would break in the first 48 hours if it stopped working?

2. For each load-bearing integration: has this been tested end-to-end in the last 6 months? Are there known data quality issues that the business is working around?

3. What is the cumulative admin burden of maintaining these integrations — in hours per month across your RevOps and engineering teams?

4. If you were rebuilding this system from scratch today, which integrations would you rebuild, which would you replace with native CRM functionality, and which would you simply not rebuild?

The answer to question 4 is usually the most revealing. It separates integrations that genuinely reflect your business complexity from integrations that reflect the limitations of your current platform.

The Real Question Underneath All of This

Integration complexity is a legitimate operational concern. But it's worth being honest about what it's sometimes standing in for.

The organisations that have the most complex CRM integration landscapes are almost always the ones that have been compensating for CRM limitations the longest. Each integration was, at some point, a workaround for something the CRM couldn't do natively. Over time, those workarounds become load-bearing. The system becomes harder to change not because it's well-designed, but because it's been patched in so many places that removing any one patch risks pulling something else loose.

This is a genuine problem. But it's also a self-reinforcing one. The longer you stay, the more patches accumulate, the harder it becomes to leave. The integration argument gets stronger every year you use it.

There's no clean answer to this. Integration complexity is a real cost and a legitimate consideration. But it's worth asking — once, honestly — whether the complexity you're managing is an asset or a tax. Whether you've built something genuinely powerful, or whether you've built something genuinely complicated. Those are very different things, and they lead to very different recommendations.

Run the integration audit above before any vendor conversation. The output — a clear list of what's load-bearing, what's convenience, and what's a ghost — will make every subsequent decision cleaner, whether you stay or switch.