What did your software and system integrations cost you last year?
Most IT leaders can answer that question, and most are far off without realising it. They know what they paid for platforms, roughly what the build consumed in developer time, and the maintenance work that came with it. The part they miss arrives after go-live and sits in nobody's budget line: what it costs the business when an integration stops working. It is usually the larger number, and one that keeps growing over time.
Key takeaways
- Integration total cost of ownership (TCO) has three buckets: building it, running it, and the business disruption caused when it stops working. Most business cases count the first and part of the second.
- The build is a one-time cost. The run and the disruption compound for as long as the integration exists, which for a working integration is measured in years.
- Disruption costs land outside IT budgets. Lost productivity, decision-making that goes dark on information, missed service levels and stalled projects surface as missed revenue and profitability targets, and are rarely traced back to an integration.
- The variables that move the TCO number most are change frequency, the number of systems and parties involved, and who carries accountability when something breaks.
- The operating model, not the platform, decides whether you absorb that cost. Buying tools leaves the run and the disruption with you. Buying outcomes moves them to a provider, at a subscription you can forecast.
Get the framework in full. The Integration Ops book sets out how the lifecycle of an integration is planned, run and measured under a Managed Integration Service. Download the book.
What is the total cost of ownership of an integration?
The total cost of ownership of an integration is the full cost of that integration across its entire life: designing and building it, operating and maintaining it through every change to the systems it connects, and absorbing the business impact when it fails. The licence fee and the project budget are only two of its inputs.
That definition matters because of where the money actually sits. In a typical enterprise integration, the build is a discrete, visible, budgeted event. Everything after it is diffuse. It arrives as escalations, as hours borrowed from other projects, as a support ticket that turns out to be a mapping change, and as the occasional day where a process the business depends on simply stops. Our earlier guide to calculating and controlling the cost of service integrations covers the visible half of this in more detail.
The three cost buckets of software integration
Bucket one: building it
This is the bucket every organisation already counts. Requirements, design, development, testing, and the coordination overhead of getting two or more parties to agree on a data contract.
It is countable because it has a start and an end. A project was opened and closed, and the finance system has a number attached. For most organisations this is the entire integration business case.
The Integration Ops book describes project-based integration delivery as a trap disguised as a process. The trap is not that the project costs too much. It is that the project ends, and the integration does not.
Bucket two: running it
The day after go-live, the delivery team is stood down and reassigned. The integration keeps working. For a while.
Then one of the systems it connects gets upgraded. A partner changes an API. Someone adds a field. A certificate expires. A volume spike that nobody modelled arrives on a Monday morning. Each of these is small. Each pulls somebody back. Running cost has four parts, and only the first is usually in a budget:
- Platform and infrastructure. Licence, connectivity, environments. The visible line.
- Monitoring and incident response. Somebody has to notice, and somebody has to be available to act.
- Change work. Version upgrades, schema changes, new fields, new endpoints, re-authentication, re-testing.
- Knowledge maintenance. Documentation that stays current, and the fact that the person who built it has moved on.
The book treats change as the constant that integration work is designed around, and the fourth item is where most organisations lose the argument without noticing. An integration nobody understands is more expensive to keep than one that is documented, because every change to it starts with an investigation. This is also where proactive monitoring stops being a dashboard and starts being an operating practice.
Two of the four items above scale with the number of integrations. Two scale with the rate of change in the systems around them. An environment with 40 integrations across a stable set of in-house systems is a manageable run cost. The same 40 integrations across different systems and different organisations (customers, partners, suppliers, government agencies), each releasing on a schedule you have no control over, is a different business entirely.
Bucket three: business disruption
This is the bucket nobody counts, and it is usually the biggest.
"If integrations fail, hell breaks loose." -- Hanna, DNV
An IT system integration exists because a business process depends on data crossing a boundary. When it stops, the process stops, and the damage spreads well beyond the team that restores it. The engineering hours spent on the fix are real, and they are the smallest part of what the failure cost. The larger part lands across the organisation:
- Productivity drops. Processes break, manual work replaces them, and people who cannot work without the data wait.
- Decision-making goes dark. When nobody is sure which information is correct, decisions slow down, or get made on data that turns out to be wrong.
- Service levels are missed. SLA breaches carry contractual fines, and the next service review opens with the incident instead of the roadmap.
- Revenue leaks. When point-of-sale systems stop communicating, or an online order cannot complete, the sale is lost, not delayed.
- Security and compliance exposure grows. Breaches and failed audits follow integrations that nobody is watching.
- Strategic work stalls. Projects wait while people fire fight, and customers who feel the failure start to look elsewhere.
For service providers the same pattern shows up as margin, which is the angle we take in how MSPs reduce costs through managed integrations. None of these costs appear in an integration budget. They appear as missed revenue and profitability targets.
Why integration disruption cost never appears in the business case
Nobody writes a business case that assumes the integration will break. It is written by the people who will build it, at the moment they are most confident in the build, and the working assumption is that a job done well stays done. Budgeting for failure would mean planning for something everybody hopes will not happen, so it is left out. The reality is a different one, and the gap arrives as a surprise: expectations that are not met, and promises that cannot be kept.
The timing makes it worse. Before go-live, the only cost of an integration is labour, and labour is easy to forecast. After go-live the profile inverts. Labour drops to near zero as the team is stood down, then spikes irregularly as escalations pull people back. Between those spikes, business disruption accumulates at a rate nobody is measuring, because no single incident is large enough to trigger a review and no reporting line aggregates them.
There is also an accountability gap. The build has an owner. The run usually does not. The Integration Ops book names the integration owner as a distinct role for precisely this reason. Without one, the cost of an integration after go-live is real but unassigned, and unassigned cost is invisible cost. Michael at MHP put the lifecycle plainly:
"If you have a house, you never finish with the house." -- Michael, MHP
How to run your integration TCO calculation
Five steps. The output is a defensible per-integration annual figure you can multiply across the estate.
- Count the build, once. Internal effort at fully loaded cost, external effort at invoice, plus the coordination time of everyone who had to agree on the interface. Amortise it across the integration's expected life. Three to five years is a reasonable working assumption for an integration tied to a live business process.
- Count the run, per year. Platform and infrastructure attributable to this integration. Then the change work. Count how many times in the last 12 months somebody touched this integration, and what each touch cost in hours. If nobody logged it, the ticket system usually holds the answer under a different label.
- Count the incidents, per year. Failures, total downtime, and the hours spent restoring service. Include the re-reconciliation, which routinely runs longer than the fix itself.
- Price the disruption. For each incident, name the processes that stopped and the business consequence that followed. Lost productivity is the first line: people who cannot work without the data are still being paid. Wrong invoices bring disputes, a longer days sales outstanding and pressure on cash flow. A delayed onboarding pushes cash in later than planned, sometimes far enough to need a credit line, and some revenue never comes back, because a sale not made online is a sale lost. Margin erodes through consultant hours nobody can bill, falling utilisation and external experts hired at short notice. Decisions made on data that was wrong carry their own price. This step is the one organisations skip and the one that changes the answer.
- Multiply by change. Take the run and disruption figures and ask what happens if the rate of change in the connected systems doubles. In most estates it already has. The result is the number you should be planning against.
An illustrative example
The figures below are illustrative. They show the shape of the calculation and represent no specific organisation. Substitute your own.
Two things stand out, and neither is the platform cost. The build, the line every business case leads with, is under a tenth of year one and a smaller share every year after. Business disruption, the line no business case contains, is roughly 90 percent of the total and rising, because change frequency rises. The four incidents cost 3,200 in engineering time and close to a hundred times that in disruption.
What actually moves the number
Three variables dominate, and none of them is the platform. Two describe the environment the integration sits in. That is why platform selection moves the total so little.
Change frequency. The rate at which the systems on either side of the integration change, and how much notice you get before they do. Every point of change is a potential cost event in buckets two and three. An estate connected to systems that release quarterly and an estate connected to systems that release continuously have different economics with identical architecture.
The number of systems and parties. This is the complexity argument. Every additional system adds another release schedule and another data model to stay aligned with. Integrations inside your own four walls are one problem. Integrations that cross an organisational boundary, into a customer, a supplier or a partner, are another. You do not control their release schedule or their escalation path. Visa at Paulig described the starting position at a supplier boundary:
"Supplier environment is quite fragmented. All of them use their own systems... that was quite a mess." -- Visa, Paulig
Accountability. When an integration breaks at the boundary between two vendors, who is responsible for restoring it? If the honest answer is "we work it out at the time", the disruption bucket is larger than any model will predict, because the recovery clock starts with a negotiation.
The operating model decides whether you absorb the cost
Three ways to hold integration cost. Each is legitimate. They differ in who absorbs the run and the disruption, and how much of it. We have benchmarked the same three models against each other in our integration solution TCO comparison, and set out the decision itself in build vs buy integrations.
The distinction that matters is in the last three rows. Buying a platform reduces build effort and leaves the run and the disruption exactly where they were. That is a real saving and it is a smaller one than the business case usually assumes, because the platform was never the expensive part.
Buying outcomes moves the run and a defined portion of the disruption exposure onto a provider who is contractually accountable for them, which is the distinction we draw out in integration service providers compared. The cost becomes a subscription line that behaves predictably as change accelerates, which is the property finance actually wants from this category.
ONEiO operates as a Managed Integration Service on that third model. We run your integrations, you deliver your services: the platform and its 24/7 operation sit with us, together with the expert team that absorbs change, under a service level, at a subscription price that does not move when your systems do. That is the specific claim, and it is testable against the calculation above.
Bottom line on integration total cost of ownership
Every organisation counts the build. Fewer count the run. Almost nobody prices the disruption, which is why integration business cases are reliably optimistic and integration budgets are reliably overrun.
Run the five steps against one real integration in your estate before you run them across the portfolio. The first honest number is usually enough to change the conversation, because it moves the discussion from what integration costs IT to what integration costs the business.
Go-live is not the risk. Staying up is.
See what this looks like against your own estate. Schedule a 30-minute conversation with an integration specialist and walk through the calculation with your numbers.
