Forty per cent of IT budgets go on maintaining legacy systems. That's McKinsey's number, not mine - but if you're a CTO or IT director at a mid-market B2B service firm, you probably didn't need McKinsey to tell you. You can feel it. Every sprint that gets swallowed by debugging a data sync that used to work. Every Monday morning spent reconciling figures between two systems that should agree but don't. Every "quick fix" integration that's now load-bearing infrastructure nobody wants to touch.
What I want to challenge is the assumption that this is just... how it is. That your integration landscape is complex because your business is complex, and there's nothing to be done short of ripping everything out and starting again.
We can't simplify this without a complete overhaul we can't afford.
I hear this constantly. And I get it - when you're staring at a spaghetti diagram of point-to-point connections that's evolved over five or seven years, "simplify" sounds like something a consultant says before handing you a bill for half a million quid. But here's what I actually think, having spent years in these environments: most integration problems in mid-market organisations aren't caused by technical complexity. They're caused by integrations that were built reactively, by whoever needed them at the time, with no shared architecture and no testing strategy worth the name.
That's a governance problem. And no amount of middleware fixes a governance problem.
This matters because I see firms spend serious money on integration infrastructure - API gateways, event buses, the works - and come out the other side with exactly the same chaos, just more expensively housed. The tooling was never the issue. The issue was that anyone could build a connection to anything without telling anyone, and that culture didn't change when the platform did.
I was reviewing an integration landscape for a professional services firm last year - about 200 people, nothing enormous - and we counted 34 distinct point-to-point integrations across nine systems. Thirty-four. The IT director knew about maybe twenty of them. The rest had been built by various teams over the years, some by contractors who'd long since moved on. When I asked what would happen if their CRM went down for two hours, the honest answer was "we don't fully know." He said it with this slightly hollow laugh, the kind that means it's not actually funny. I've had that conversation more times than I can count, and it never gets less alarming.
The failures, in my experience, cluster around a handful of patterns.
The first is reactive construction. A new CRM gets implemented and someone builds a direct connection to the finance system because invoicing needs client data. Six months later, the marketing platform needs the same data, so another point-to-point connection gets built. Then the client portal. Then the reporting tool. Nobody sat down and said "let's create an unmaintainable web of dependencies." It just happened - one integration at a time, each solving an immediate need, none referencing a broader architecture. And because each individual decision was reasonable, nobody ever had the conversation about what they were collectively building.
The second is unclear ownership. This one's more insidious because it doesn't look like a problem until something breaks. When your CRM says a client's address is one thing and your billing system says it's another, who's right? In most mid-market firms, the answer is "whoever notices first" or "the person who shouts loudest." There's no authoritative source for each data entity, no clear escalation path when systems disagree, no decision framework for when an integration should be rebuilt rather than patched for the fourth time. The reconciliation effort this creates is invisible in any single budget line, but it's enormous in aggregate.
One firm we worked with had a finance team spending roughly 15 hours a week on data reconciliation that existed solely because two systems didn't agree on client payment terms. Fifteen hours. Every week. For years. When we surfaced that in a room with the CFO, there was a long silence. Not the thoughtful kind.
The third pattern is testing that only covers the happy path - the scenario where everything works as expected. What happens when the upstream system sends a record with a missing field? What happens during a volume spike at month-end? What happens when a vendor pushes an API update that changes the response format? These aren't exotic edge cases. They're Tuesday. And they're the scenarios that account for the vast majority of production incidents.
None of these require you to rip anything out. All of them can be adopted incrementally.
API-first design. When two systems need to exchange data, you define the contract - what data, in what format, with what validation rules - before you build either end of the integration. Not after. The analogy I use is plumbing. You wouldn't connect your kitchen sink to the mains by cutting a pipe and hoping for the best. You'd agree on the pipe diameter, the fittings, and the shut-off valve location before you start. Same principle. Treating integrations as first-class parts of your architecture rather than afterthoughts sounds obvious, but it's the exception rather than the rule in most mid-market environments I've worked in.
Clear data ownership. Every data entity in your landscape - clients, transactions, products, whatever - has a single authoritative source. Every other system treats that entity as read-only from the source. In principle, this is almost stupidly simple. In practice, getting a room of system owners to agree on which system is authoritative for which data is one of the more politically charged conversations you'll have. People are attached to their systems being the source of truth. But it eliminates the data reconciliation problem at source rather than trying to manage it downstream, which is where most firms burn enormous amounts of invisible effort.
Robust error handling. Integrations that fail gracefully, log what happened, and alert the right person. Not integrations that fail silently - so nobody knows until a client calls asking why their invoice is wrong - or that cascade failures to connected systems. This is less about technology and more about discipline. Every integration should have a defined answer to: "What happens when this fails?" If the answer is "we'll figure it out at the time," that's not a plan.
If you're nodding along but thinking "fine, but where do I actually start?" - fair.
The starting point, almost always, is the mapping exercise. Get the integration landscape on a wall - or a Miro board, or whatever you use - and look at it properly. You'll probably find connections you didn't know existed, single points of failure nobody had identified, and manual workarounds that have become so routine nobody questions them anymore. That firm with 34 integrations I mentioned earlier? Three of them were running through a middleware instance that was two major versions behind and had a known security vulnerability. Nobody knew because nobody had mapped it.
Once you've got the map, the next step is identifying which integrations are on the critical path - meaning if they fail, revenue-generating processes stop - and which failures cascade to other systems. This gives you a risk-weighted view of your landscape rather than treating every integration as equally important.
From there, you design a target state. And I want to be specific about what I mean by that, because this is where firms often go wrong. Not a utopian future-state architecture that would take three years to build. A pragmatic target that consolidates the highest-risk point-to-point connections into managed integration layers where the complexity warrants it, and leaves simpler integrations alone. Sometimes the right answer is a middleware or API gateway layer. Sometimes it's just better-documented, better-tested point-to-point connections.
Then you migrate incrementally. Rebuild the highest-risk integrations first. Prove the approach. Build confidence. Move to the next one. Not a big-bang programme - a rolling improvement cycle.
BCG found that two-thirds of large technology programmes miss their targets on time, budget, or scope. The ones that fail usually tried to do everything at once.
Even with good intentions and the right principles, a few patterns reliably derail this work.
The combinatorial maths of point-to-point connections is worth understanding properly. Five systems that all need to exchange data with each other give you up to 20 integrations. Add a sixth system and you're at 30. A seventh takes you to 42. It compounds fast, and it gets unmanageable faster than most people expect. An integration layer means each new system needs one connection to the layer, not connections to every other system. But introducing that layer requires architectural discipline and buy-in from system owners who are used to just building a direct connection when they need one. That cultural shift is harder than the technical work.
The opposite trap is over-engineering - building an enterprise-grade integration architecture for a landscape that has nine systems and a team of four developers. I've seen firms spend £200k on integration infrastructure that a well-documented set of REST APIs would have handled perfectly well. Match the solution to the problem, not to the architecture diagram you saw at a conference.
And then there's data quality, which isn't a separate workstream from integration improvement - it's a prerequisite. An integration that reliably moves dirty data from System A to System B hasn't solved anything. It's automated the propagation of the problem. If your CRM has 15,000 client records and 3,000 of them have incomplete or inconsistent data, connecting that CRM to your billing system with a beautifully engineered API doesn't improve your billing accuracy. It just makes the inaccuracy faster. This is also why so many organisations find their data isn't AI-ready even when the systems themselves might be - dirty, inconsistent data flowing through integrations is one of the primary reasons AI projects stall before they start.
If you're a CTO reading this, you probably already know what needs to happen. The harder question is getting a managing partner or CFO to fund it, because "integration architecture improvement" doesn't exactly set hearts racing in the boardroom.
So translate it. The value shows up in places that non-technical leaders actually care about.
Processes that depend on reliable data flows move faster when those flows work without manual intervention. Client onboarding that takes three days because someone has to manually re-key data between systems could take three hours. Month-end reporting that requires a week of reconciliation could take a day.
When the same client shows different revenue figures in your CRM, your billing system, and your management reporting tool, someone has to decide which number is right before any strategic conversation can happen. That reconciliation effort is invisible but enormous. Consistent data from a single authoritative source eliminates it.
And the manual processes that compensate for unreliable integrations - the spreadsheets, the re-keying, the "just checking" emails between teams - are typically invisible in any single budget line. Nobody has a line item for "time spent working around broken integrations." But when you make that effort visible and add it up, it's often tens of thousands of pounds a year. Sometimes more. That finance team spending 15 hours a week on reconciliation? That's roughly one full-time employee, every year, doing work that should be automated. Put it in those terms and the conversation changes.
Honestly, for most firms, it's the mapping exercise. Get the integration landscape visible. You'll probably be surprised by what you find - and sometimes just making the invisible visible is enough to get the right conversations started.
If you want to go a step further, we've put together an integration health checklist that maps your current landscape against the root causes of integration failure and the common traps. It takes about an hour and tells you where the highest-risk points are. It's designed for a CTO or IT director, but it's structured so you can share the output with a managing partner or CFO as part of an investment conversation.