In the B2B SaaS integration space, there are regular discussions about which integrations to build next. Which ones will close deals, reduce churn, open new market segments, or provide an edge over the competition. And we should be talking about this because integrations are one of the highest-leverage investments on your product roadmap.
But many product teams don't address the obverse: which of our existing integrations should we stop supporting?
It may even seem like a strange question. Integration breadth is generally a good thing. Customers are always asking for more integrations. Sales wants to say yes to more integrations. And once an integration is live, the path of least resistance is to leave it.
They're not broken, exactly. They just aren't doing anything. Nobody's enabling them. Nobody's using them. But they're in your marketplace, still sitting on your infrastructure, still requiring security, and still on the hook for someone to manage.
So, "Can you have too many integrations?" Yes. Not because integrations are bad, but because the cost of maintaining some of them exceeds their value. At some point, an integration that was once an asset becomes a liability.
And your goal is a healthy integration catalog, no matter what size that is.
What is a zombie integration?
A zombie integration is technically alive but delivers zero or negative net value. More precisely, it fits one or more of these descriptions:
- It has zero or near-zero executions in the last 90 days
- It was built for one or two customers who have since churned, and nobody else picked it up
- It relies on an API version that has been deprecated or is no longer actively maintained by the third party
- It's being kept around "just in case" it's needed
The tricky part is that zombies don't announce themselves. They look alive until you pull the usage data. And since most teams aren't regularly auditing that data, zombies can accumulate for months or years.
Zombies can come in slightly different forms:
- Some were built to close a specific deal or satisfy a specific customer request. Maybe that worked and they helped you land the account. But the customer churned, or stopped using the integration, and nobody else ever enabled them. They’ve been sitting untouched ever since, and no one internally owns them.
- Others were genuinely useful at some point. Your customers needed them, your team built them, and they served their purpose. But the third-party tool they connected to lost market share, changed its API model, or fell out of your ICP's tech stack.
- Then, there are bespoke integrations that were built under deal pressure, and somehow ended up with your standard integrations. However, the documentation is thin, and they generates the occasional ticket from customers who wonder what they do.
The cost of maintaining zombies
Sometimes, when discussing a zombie integration, you'll hear: "It's already there. Removing it takes more work than just leaving it. What's the harm?"
This sounds reasonable until you look at what maintaining a zombie actually costs.
- Engineering bandwidth – Every integration is a dependency on a third-party system. Third-party systems change, APIs version, auth flows break, and libraries deprecate. When that happens, your devs start fixing code that no active customer is using. Some teams find they're burning 20–30% of their integration budget on maintenance for low-value integrations.
- Security surface – A dormant integration isn't completely inert. It may still hold OAuth tokens or stored credentials tied to customer data environments. Unmonitored webhooks, outdated auth flows, and unpatched libraries are compliance and security liabilities that are unlikely to be flagged, because nobody's actively watching them.
- Customer trust – A bloated marketplace creates decision fatigue. When customers open your catalog and see 150 integrations, they start to wonder: which of these are actively supported? Which ones will actually work today? The more noise in your catalog, the harder it is for customers to find the integrations that matter to them.
- Roadmap friction – Zombie integrations carry ghost votes in your prioritization process. "We already have an integration with X, let's just update it," makes good sense. However, that argument collapses if X is deployed only to three accounts that churned last quarter. Poor data leads to poor prioritization.
- Opportunity cost – Engineering hours spent keeping a zombie going are hours largely wasted. That trade-off rarely shows up in sprint planning, but it's happening behind the scenes.
Step 1 – Audit your integration catalog
You don't need a six-month audit project (more than likely). Most teams can identify zombies in under 30 days with the right data. The difficult part isn't so much the analysis but accepting what the numbers are telling you.
Pull usage data
For every integration, gather:
- Execution volume – How many times did it run in the last 90 days? Zero or near-zero is a primary deprecation signal.
- Active deployment count – How many customers have it enabled right now? And are those customers active?
- Error rate – High error rates on low-deployment integrations mean something is broken, and nobody's noticed because nobody's using it.
- Support ticket volume – Which integrations are driving inbound support load disproportionate to their usage? If something accounts for 15% of your integration support tickets and 2% of your active deployments, that integration needs a hard look.
- Engineering time – Which integrations are generating the most unplanned work? Your version history and sprint logs are a good source for this.
If you're using an embedded iPaaS like Prismatic, most of this data lives in one place since usage analytics, execution logs, and version history are built in.
If you're managing integrations via custom code, the audit itself will show you the value of an embedded iPaaS.
Map integrations to active customers and segments
Raw numbers won't tell the whole story. Three deployments could mean three churned non-ICP accounts or three important companies in a vertical you're actively investing in. You need to look at who is using each integration, not just how many.
Tag every integration with the customer segments it serves. Is it deployed by customers in your ICP? Is it tied to a vertical or a tier that feeds your growth strategy? Are those customers on track for renewal, or have they already been flagged as churn risks?
An integration with three strategic deployments may be more valuable than one with fifty on accounts you'd have a hard time naming.
With usage data and customer segment context in hand, build a simple scoring matrix. Rate each integration from 1 to 5 across four dimensions. Here's what the matrix might look like (leaving out 2 through 4 for space). Adjust as needed to make sense for your specific situation.
| 1 (Low) | 5 (High) | Weight | |
|---|---|---|---|
| 90-day usage | Zero executions | >20% of customer base running it regularly | 40% |
| Maintenance load | >20 dev hrs/quarter | <2 dev hrs/quarter | 30% |
| Business value | No revenue tied, no ICP alignment | Directly tied to expansion, retention, or strategic verticals | 20% |
| Risk | Outdated auth, deprecated APIs, or compliance exposure | No known issues. | 10% |
Rank your integrations and segment the results
- Keep and invest – High usage, ICP-aligned, clear strategic value. These deserve continued updates and maintenance.
- Monitor – Low-to-moderate usage but with identifiable strategic importance or used by a small number of high-value customers. Set a review threshold: if usage doesn't grow within X time, integration is moved to deprecate.
- Deprecate – Low usage, no ICP alignment, high maintenance burden, or built for inactive customers. These are your zombies.
Once you have these categories populated, hold a brief cross-functional review with the involved teams (probably product, engineering, CS, and sales). Zombies are shockingly obvious once everyone gets to look at the same data together.
Step 2 – Decide what to deprecate
Not every low-usage integration deserves deprecation. Use the following as decision filters (or as a starting point for defining your own decision filters based on your specific situation).
Hard triggers for deprecation
- Zero executions in 90+ days, with no strategic customer using it
- Vendor has officially deprecated the API version that integration relies on
- Security or compliance exposure that can't be fixed quickly or cost-effectively
Softer factors to consider
- Is a small but high-ACV set of enterprise customers still using it? If so, deprecation may not be the right approach. But migration might make sense.
- Does it support a strategic vertical, even if current usage is low?
- Is there a low-friction migration path for affected customers?
Every integration should earn its place. If you can't make a clear case for why something belongs in your catalog, you have your answer.
Step 3 – Deprecate without breaking trust
Deprecation is a product decision. Handled well, it builds customer trust. Handled poorly, it ends up in a CSM's escalation queue the week before the customer contract renewal.
Communicate details early
Give customers at least 60–90 days advance notice – more for enterprise customers with complex implementations. Be specific about the deprecated integration, what breaks on what date, and the recommended alternative.
Vague notices will generate more anxiety and support tickets than clear, specific ones. Customers can plan around actual timelines. And transparent reasoning (such as explaining that removing low-value integrations lets you invest in the integrations are using) lands better than a bare announcement.
Provide a migration path
When a successor integration or alternative workflow exists, make it easy to find. Is there a better-supported integration in your catalog, a native workaround, or should the customer use the embedded workflow builder to cover the use case without involving engineering at all? The more you reduce possible friction, the cleaner the deprecation. Even a brief "here's what we recommend instead" in the outreach goes a long way.
Set a date and stick with it
Soft deprecations tend to stay open indefinitely. Customers don't migrate because there's no urgency. Your team keeps fielding questions and applying patches. Six months later, you've achieved nothing.
And so easy to lose. Make sure you manage the deprecation process while keeping in mind how your customers will view your decisions and actions.
Set a specific end-of-life date. Communicate it clearly. Then, make it happen. If an enterprise customer makes a compelling case for an extension, handle that as a deliberate exception.
Align internal teams before talking externally
Before you send a single deprecation notice, make sure CS and your AEs are aligned. CS needs to know which accounts will be affected. AEs need to be ready to answer questions from accounts with pending renewals (or new deals in play that might depend on the integration being available). Learning about a deprecation from a customer escalation isn't good.
After deprecation, make sure you do a full cleanup
Remove the integration from your public marketplace, documentation, sales collateral, and demo environments. A deprecated integration that generates support tickets suggests your catalog isn't actively managed, which isn't the message you are trying to send.
Inoculating against the next crop of zombies
A one-time audit cleans up what you have today. Then, put some governance in place to make it unlikely you'll need to do it again.
- Set acceptance criteria before you build – Every integration added to your catalog should have a defined threshold it's expected to hit within a set window after launch: a minimum number of active deployments, a usage floor, or a revenue tie. If it doesn't hit that threshold, it goes into active review. This is how you catch low-traction integrations early, before they age into maintenance obligations.
- Assign lifecycle ownership – Every integration should have a clear owner responsible for monitoring its health and making the call when it's no longer earning its place. That's how you get a ghost integration: nobody knows who built it, nobody's watching it, and nobody wants to touch it.
- Build for reuse, not one-offs – One-off integrations built under deal pressure are the primary source of integration sprawl. When every integration is a custom build, it becomes a separate maintenance burden. Standardizing on a platform with reusable components and pre-built architecture means fewer zombies get created in the first place. And, the ones that do show up are easier to retire cleanly.
- Treat integration health as a product metric – Deployment rate, execution volume, error rate, and support ticket volume belong alongside retention and feature adoption in internal product reviews. When integration health is visible at the product level, problems show up earlier, and decisions are made with actual data instead of gut feelings and stakeholder advocacy.
An embedded iPaaS gives you the infrastructure to do all of this in a governed environment: real-time usage and health visibility across every integration, built-in logging and monitoring, reusable components that are easy to update or retire, and self-service configuration that keeps customers in control of their own integrations. Instead of custom code sprawl that breeds zombies by design, you get a catalog of integrations that's built to be monitored, managed, and (when the time comes) retired cleanly.
A healthy integration catalog is the goal
Integrations are still one of the best investments you can make in your product. Products with strong integration portfolios retain customers better, close deals faster, and expand into new markets more efficiently.
However, integration catalogs need the same active management as the rest of your product. After all, core product features get deprecated, and pricing tiers are restructured. Integrations should be handled no differently.
A healthy integration catalog is credible. It's easier to support, easier for customers to navigate, and a cleaner signal to the market. Instead of trying to make everyone happy, you focus on connecting deeply to what actually matters for your customers.
And you free up the dev capacity you need to build the integrations that will drive your next phase of growth, instead of maintaining those that are just taking up space.
Prismatic gives product teams the monitoring, logging, and deployment visibility they need to maintain healthy integrations. Check out our free trial and see how we help you keep the zombies at bay.
Part 1 of this post covers how many integrations you should have and part 2 addresses the long-tail integration problem.
