How I compare iPaaS tools and integration services in 2026
Many evaluations compare integration platforms in fine detail. The thing that decides whether the integrations work afterwards is usually not on the scorecard.
The enterprise integration evaluation has a standard shape. Three vendors, a scoring matrix, a proof of concept, weighted criteria for connectors, transformation, monitoring, governance and price. Weeks of work, a recommendation, a signature.
Then, eighteen months later, the same organisation is having the same conversation about a different iPaaS tool.
The comparison is not badly run. It answers its question accurately. The problem is the question itself: which platform is best says nothing about who keeps the integrations running after go-live, and that is what decides the outcome.
The platform vendors’ own numbers show the problem
MuleSoft surveys IT leaders every year, and the 2026 edition of its Connectivity Benchmark reports that the average enterprise now manages 957 applications with 27% of them connected, while IT teams spend 36% of their time designing, building and testing custom integrations. The year before, the same study reported 897 applications, 29% connected, 39% of time.
Two decades of increasingly capable integration platforms have produced an environment where roughly three quarters of applications remain unconnected and integration still consumes more than a third of IT’s time.
Modern iPaaS platforms are genuinely good. The connectors work, the mappers work, the monitoring dashboards are perfectly decent. So the gap between what these platforms can do and what enterprises actually have connected is not a functional capability gap. It is an operating capacity gap: the hours to run what the platforms build are not there.
What the scorecard measures stops at go-live
Every criterion in a platform comparison describes the work between signature and go-live. Better, faster, cheaper to build. That phase is real, and it is the short one. The years after go-live are where an integration earns its keep and causes its trouble: endpoints change, partners migrate systems, certificates expire, and each of those events needs someone to notice it and fix it. The scorecard measures none of that.
Switching integration platforms is also far more expensive than the scorecard admits. One iPaaS vendor that sells tooling to make integration migration easier describes the pre-tooling reality plainly: a realistic migration of several hundred workflows was a 6-to-12-month project, because existing workflows “represent months or years of accumulated logic. Field mappings, error-handling branches, retry logic, conditional routing. All of it encoded in a proprietary format”, documented “(if you were lucky) across a mix of internal wikis and institutional memory”.
So when an evaluation concludes that platform B scores 8% higher than the platform you own, the proposal on the table is to spend two to four quarters of senior engineering time improving the one phase of the lifecycle that was never the constraint. Very few organisations go through with it. Most keep the platform and stay stuck, which is the rational response to a badly framed choice.
The question that should replace it
Ask the question the platform comparison never asks: will the new platform prevent integrations from failing and disrupting the organisation?
No vendor will promise that, because most integration failures start in the endpoints, the credentials and the partner systems around the platform. The platform can be perfectly healthy while the order flow it carries is down. So the useful question is who operates the integrations after go-live, and who is accountable when one of them stops.
That question opens up the real set of alternatives. Most buyers know three: build integrations in-house, buy a platform and operate it yourself, or bring in a systems integrator to deliver them as a project. There is a fourth option many organisations have never evaluated, simply because they did not know it exists: a service that someone else runs continuously, under a contractual commitment, with the operating work and the accountability included.
Every one of these options gets you built integrations. They differ in who does the ongoing work and who carries the risk when something breaks. In-house builds and self-operated platforms keep both with your team. A project delivers the build and hands the maintenance back to you at go-live. The continuous service moves the operating work and the risk to a provider, and costs you some autonomy in exchange. All four are legitimate choices with real trade-offs. The evaluation worth running compares those trade-offs against where your organisation aspires to go, and asks which risk you can least afford to carry.
Why the industry frames it as a platform swap anyway
Displacement is a larger contract. A vendor who tells you your MuleSoft instance can stay is describing a smaller sale than one who tells you it should go.
Get Janne Kärkkäinen’s stories in your inbox
Join Medium for free to get updates from this writer.
There is a second reason, less cynical. Procurement knows how to run a tool selection. There is a category, a budget line, a comparison template, a decision date. So organisations run the process they know how to run, and get an accurate answer to a question they did not need to ask.
What an honest evaluation looks like
Comparing approaches to integration feels unfamiliar because the choice has no ready-made category, it crosses two budget lines, and its benefits show up as things that stop happening. In practice it comes down to three questions, none of which appear on a standard scorecard.
Which parts of the integration lifecycle do we actually want to own? Most teams, asked directly, want to keep the design decisions and the business logic. Almost none of them want the credential rotation, the version chasing, or the overnight escalations. Those are separable.
What happens on the day something breaks? Walk the sequence: who notices, how fast, who they call, what they are contractually owed. Then keep walking past the IT part, because an integration failure rarely stays inside IT. While the team firefights, the process the integration carries has stopped: orders wait, tickets stop syncing, customers notice, service level penalties start accruing, and somewhere a renewal conversation gets harder. The cost of a failure is measured in the business that stops, not in the engineering hours spent restarting the flow.
What does each option cost over the whole lifecycle? Building an integration is the cheap part. Operating it, changing it and repairing it recur every year for as long as the connection matters, and those costs land on payroll, where no platform invoice shows them. Price every option on the years after go-live. And time the decision against your platform contract: licences are term subscriptions, so whatever you decide reaches the run rate only at renewal.
Answer those three and the decision usually makes itself, without anyone scoring a connector library.
The uncomfortable question
When your integration platform was selected, who in the room was going to be responsible for operating the integrations it produced?
In most evaluations that person was not present, was not consulted, and inherited the outcome. That points at the qualifying question every shortlist should face: how each option performs after go-live at keeping the integrations running, and who is accountable when one fails. Any serious option can design, build and test. Score them on what happens next.
Bottom line
The integration platform was rarely the problem, so a better platform was never going to be the fix. Migration costs quarters, the logic sits in proprietary formats held together by institutional memory, and the constraint is operating capacity that no tool purchase adds.
The comparison that matters is between approaches to integration and what each one covers after go-live. Before your next integration platform decision, ask five questions:
- Which parts of the integration lifecycle do we want to own, and which do we want off our plate?
- When an integration fails, what stops beyond IT: which processes halt, which customers feel it, which commitments and revenue are at risk?
- Who is accountable, by name and in writing, for keeping each integration running after go-live?
- What does each option cost over the full lifecycle, including operation, change and repair?
- When does our current platform contract renew, and what do we want to be true by that date?
An organisation that can answer those five does not need a scoring matrix. The answers point at the approach, and the tooling becomes what it always should have been: an implementation detail somebody else can worry about.
About Integration Operations
Integration Ops brings operational discipline to integration management. Plan. Build. Monitor. Operate. Continuously. It’s what DevOps did for software delivery and SecOps did for security, applied to the integration domain.
