You are outsourcing the wrong IT work

Look at what your organisation has already outsourced.

Tier-one help desk. Infrastructure monitoring. Backup and disaster recovery. Email security. Probably the cloud your systems run on, and quite possibly the endpoints they run against.

Now look at what stayed.

Strategy stayed, correctly. Security architecture stayed, correctly. Vendor management stayed, correctly. And the integrations stayed, and nobody has ever explained why.

Not because anyone decided to keep them. Nobody decided anything. The integrations stayed in-house the way furniture stays in a house you inherited. They were there, they worked, moving them seemed like more trouble than living with them.

So the one part of your operation that touches every other part, and that fails in the most visible way possible, is the one part you are still doing yourself, with the people you have, in the time they do not have.

The test everybody uses

The outsourcing conversation almost always runs on a single question. Is this work standard enough that somebody else could do it?

Help desk passes easily. Password resets look the same everywhere. Monitoring passes. Backup passes. These are well-defined services with mature markets, and you can write an SLA for them in an afternoon.

Integration fails that test immediately, and it fails it for a reason that sounds convincing. Our integrations are ours. Our field mappings encode fifteen years of decisions about what a customer actually is. Our largest client has a change process that no external supplier could possibly navigate. This is bespoke work. You cannot outsource bespoke work.

That reasoning is sincere, and it is wrong, because it has quietly swapped one word for another.

Bespoke is not the same as strategic

Strategic work is work that, done well, creates advantage you can point at. It changes what you can sell, what you can promise, what you can charge.

Bespoke work is just work that has not been standardised yet. It might be strategic. It very often is not. Your field mappings are specific to you in the same way your payroll is specific to you, and you outsourced payroll a decade ago without a moment of soul-searching.

The confusion is expensive because it inverts the decision. The teams I meet keep integration in-house on the grounds that it is too particular to hand over, while handing over the help desk, which is the only function in the list that actually talks to their customers every day.

Ask what your integration work is buying you strategically. Not what it enables. What the act of doing it yourself buys you. In almost every case the honest answer is nothing. It buys you an engineer who knows how it works and cannot go on holiday without a laptop.

The list that should stay is shorter than you think

To be clear, there is a genuine keep-in-house list, and the traditional one is right.

• IT strategy and architecture. Where the estate is going, and why. Nobody can want your outcomes on your behalf.
• Security architecture and access policy. Not the tooling. The decisions.
• Vendor relationship management. Especially as you outsource more. Somebody in-house has to own who is accountable for what, and that job gets more important the more suppliers you have, not less.
• Incident response and continuity planning. The judgment calls under pressure. The plan can be written with help. The decisions cannot be delegated.

Read that list carefully. Every item is a decision-making function. Not one of them is a run function.

That is the pattern, and it holds. What you keep is the thinking. What you hand over is the doing, especially when the doing is continuous, unglamorous, and completely unforgiving of a bad Tuesday.

Integration is the most continuous, most unglamorous, least forgiving run function in the entire estate. By the logic your own organisation already applies, it should have been outsourced first. It usually goes last, if it goes at all.

Why it feels different, and why that feeling is a trap

Three arguments come up every time, and each one deserves a straight answer.

"We would lose control." You would lose execution. Control is knowing what integrations exist, what data they move, who owns them, and what happens when one fails. Most teams running integrations in-house cannot produce that list on request. Executing something badly is not the same as controlling it.

"Nobody else understands our environment." They understand it because they built it, and they built it in an order that made sense at the time. That is not understanding. That is memory, held by one or two people, undocumented, and one resignation away from being gone entirely.

"It is cheaper to do it ourselves." It is cheaper on the line item where you look. The cost of integration work does not sit in a budget. It sits in SLA breaches you never traced back to a broken data flow, in the onboarding that slipped a quarter, in the two senior engineers who spent the year on connectors instead of on the thing you actually sell.

Each argument, examined, turns out to be an argument for a person rather than an argument for a capability.

What handing it over actually looks like

The reason integration outsourcing has a bad reputation is that most people have only seen one version of it: the project. Bring in a firm, scope the work, get the connectors, sign the handover document, and inherit the operations anyway. That is not outsourcing the work. That is outsourcing the build and keeping the run, which is precisely the wrong half.

Outsourcing integration properly means the run goes too. Somebody else monitors the flows, absorbs the API changes, rotates the credentials, handles the new endpoint when you sign a new client, and carries an SLA on the outcome. Your team keeps the decisions: what connects to what, what data crosses, what the business needs next. That is the Integration Ops split, and it maps exactly onto the split your organisation already made with monitoring and backup.

"Unbothered. I think that's the thing, how it changed us. We use our time to do other things, to monitor other things instead of the data exchanges." That is Dmitri at the City of Espoo.

Unbothered is an underrated outcome. It is also, if you are honest, the actual goal of every outsourcing decision you have ever signed.

The uncomfortable question

If integration work is genuinely too strategic to hand over, then it deserves a strategy, a budget line, a named owner, and a seat in the operating review.

Does it have any of those? Or is it strategic only in the conversation where somebody suggests giving it to a supplier, and back to being invisible plumbing every other day of the year?

You cannot have it both ways. Either it matters enough to resource properly, or it is run work that belongs with a supplier who will resource it properly for you.

Bottom line

The outsourcing decision is not about what is standard and what is special. It is about what is a decision and what is an operation.

Your organisation already knows this. It applied the rule to infrastructure, to backup, to security tooling, to the help desk. It just never applied it to the layer that connects all of them, because that layer never showed up as a category on anybody's list.

Put it on the list. Then ask the only question that matters: is anyone in this organisation genuinely better off because we insist on operating our integrations ourselves?

If the answer is one engineer's job security and nothing else, you have your decision.

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.