Of IT Team Time
spent on custom integrations
Of Apps Connected
average across enterprises
Weekly Per Team
on legacy system dependencies
Ask your VP of Engineering a simple question: What percentage of your team’s capacity goes to keeping existing integrations running?
Don’t ask for the number they report upward. Ask for the real number. The time spent debugging a data transformation that broke after a vendor API update, the weekend firefight when the OMS-to-ERP sync failed and 800 orders got stuck, or the three-hour investigation into a schema drift in the PIM feed that nobody noticed for two weeks. If they’re honest, the answer will be somewhere between a quarter and a third of their total capacity. MuleSoft’s 2025 Connectivity Benchmark—based on interviews with over 1,000 IT leaders globally—found that IT teams spend 39% of their time building and maintaining custom integrations. Not shipping features or building competitive advantage or responding to business needs. Just keeping the connections between systems alive.
That’s not just an IT problem, although IT is certainly bearing the brunt of it. It’s also a P&L problem that gets worse every year. As your commerce stack grows—new channels, new platforms, new partners—the number of integration touchpoints grows with it, but the team responsible for keeping those connections alive doesn’t scale at the same rate. The math only runs one direction.
The Capacity Tax
Your integration engineers aren’t a line item labeled “integration maintenance.” They’re on the same team that’s supposed to be building your next OMS rollout, your new B2B portal, your platform migration. Every hour they spend patching a broken connector between your ERP and your ecommerce frontend is an hour they’re not spending on the project your CEO asked about in last quarter’s board meeting. The opportunity cost of that work is enormous.
Survey data from Retool found that IT and engineering teams spend 40% of their time building and maintaining internal tools and workflows rather than building products that drive revenue. In manufacturing and distribution environments, the problem intensifies: 64% of organizations report that legacy system dependencies consume 16 or more hours per week in engineering effort. That’s effectively two full-time engineers doing nothing but keeping systems talking to each other.
Because this work is reactive—break-fi x, fi refighting, “we’ll clean this up later”—it resists every attempt to plan around it. You can’t roadmap a production integration failure or sprint-plan around the vendor update that changes an API response schema on a Tuesday. The work is inherently unpredictable, which means it consumes whatever capacity is available, whenever it needs to.
The result is a paradox that every VP of Engineering recognizes but few can quantify: your most experienced engineers—the ones with the deepest institutional knowledge of how your systems actually connect—are the ones who get pulled into integration fi refighting most often. They know which API has the undocumented rate limit, which data transformation has the edge case that drops records, which batch job has to finish before another one can start. That institutional knowledge makes them indispensable for maintenance and unavailable for innovation.
What the CFO Should Be Asking
If integration maintenance is consuming a third of your engineering capacity, that’s a number your CFO needs to see, framed as what it actually is.
Take a team of six engineers. Average fully-loaded cost in North America for a senior integration engineer: $180,000–$220,000 per year. If two of those six are functionally dedicated to integration maintenance—even though their title says something else—that’s $360,000–$440,000 per year in labor that never appears on any integration budget line. It’s buried in “engineering headcount.”
Now layer on the opportunity cost. Those two engineers aren’t building the multi-broker OMS orchestration your distribution team has been asking about for 18 months. They’re not automating the order routing logic that would save your ops team 30 hours a week. They’re fixing the same Kafka consumer group that crashes every time your PIM vendor pushes a schema update.
This is what it looks like when an IT problem is actually a P&L problem:
Direct labor cost: 39% of IT time on integration is a quantifiable burn rate that competes with every strategic initiative on the roadmap.
Opportunity cost: Every sprint ticket spent on integration fi refighting is a sprint ticket not spent on the platform improvements your business teams are waiting for.
Risk cost: Reactive integration management means you’re always one vendor update, one peak event, or one system migration away from a production incident that costs real money.
Hiring cost: When your best engineers burn out on maintenance work that doesn’t challenge them, they leave. The replacement takes six months to reach the same institutional knowledge level.
The Industrial Multiplier
If you’re in manufacturing or distribution, the math gets scarier. The integration surface area is larger, the systems are more complex, and the cost of failure is higher.
A typical enterprise distributor is running an ERP, an OMS (often multiple), a WMS, a PIM, an ecommerce frontend, a CRM, and a growing ecosystem of supplier and logistics integrations. Every new supplier, warehouse, and channel adds integration surface area. Unlike retail—where the peak-event cycle creates natural urgency—industrial B2B integration failures tend to be chronic and compounding rather than acute.
The industry data backs this up: manufacturing and distribution inside sales teams still spend 40%+ of their time on manual email or phone processing. The average cost of a single order processing error in complex distribution environments is $18,000—not because the error itself is expensive, but because it cascades. A wrong order triggers a return, a reshipping, a customer credit, a capacity reallocation, and a downstream scheduling failure. Each manual touchpoint is also an integration gap.
Every time you expand, the integration layer has to grow with you. If that layer is held together by custom scripts, batch jobs, and a senior engineer who “just knows how it works,” your growth trajectory has a built-in ceiling that nobody’s measuring.
IM&D companies often discover this ceiling at exactly the wrong moment. An acquisition closes and the integration team needs to onboard a new ERP and three new supplier connections in 90 days. A key customer demands EDI compliance, and the only person who understands the existing EDI integrations just gave two weeks’ notice. A new warehouse comes online, and the WMS integration that worked for one location doesn’t scale to two without a rewrite.
From Cost Center to Competitive Advantage
The companies that are getting this right are making a structural shift: they’re treating integration as a discipline, not a chore.
That means separating the integration layer from the platform teams and giving it its own accountability, monitoring, and operational model. Not because internal teams can’t do the work—they can. But because the organizational structure rarely lets them prioritize it at the level it demands. Integration maintenance always loses the sprint planning battle to feature development, until it breaks, and then it’s the only thing anyone works on for three days.
The shift looks like this: instead of distributing integration responsibility across every team that touches a system boundary, you create a single integration discipline that owns the connections between all systems. Instead of reacting to failures, you monitor continuously and catch anomalies before they cascade. Instead of treating integration as a one-time project deliverable, you treat it as an ongoing operational commitment the same way you treat the platforms themselves.
When you make this shift, the P&L math changes. The 39% of engineering time that was going to maintenance gets redirected to strategic work. The fi re drills stop crowding out the roadmap. The cost of integration doesn’t disappear, but it moves from a hidden, unaccountable drain to a visible, managed investment with clear returns.
That’s the conversation your CFO should actually be having: not “how do we reduce IT spend,” but “how do we redirect the integration spend we’re already carrying toward something that compounds instead of decays?”
The Question to Take to Your Next Budget Review
Pull the last 12 months of engineering tickets. Tag the ones that are integration-related: break-fi x, data sync issues, API failures, schema drift, vendor update impacts, production incidents traced to a system boundary. Total the engineering hours. Multiply by your average fully-loaded cost.
That number is your current integration spend. It’s already on your P&L, it’s just lost in a broad engineering bucket.
The question isn’t whether you can afford to invest in integration differently. It’s whether you can afford to keep paying for it this way, and keep losing the engineering capacity that should be building your competitive advantage.
The integration tax compounds. Every year you don’t address it, the integration layer gets more complex, more fragile, and more expensive to maintain. The engineers who understand it get more senior and more expensive, the technical debt accumulates, and the gap between what your business needs and what your technology team can deliver keeps growing—not because your team isn’t talented, but because their talent is being spent in the wrong place.