Published on 05/01/2026
By Peter Holroyde
Most businesses do not have “a system”. They have a collection.
A CRM that someone likes, a finance tool the accountants can tolerate, an HR platform nobody opens, a few SaaS subscriptions that seemed sensible at the time, and a couple of spreadsheets that quietly run the place.
On a good week, it mostly works. On a bad week, you find two versions of the same customer, two different addresses, three different “statuses”, and a team arguing about which screen is telling the truth.
How much time do you spend re-keying data just to make that collection behave? If all your tools talked to each other, what would change first?
Customers feel it too. They do not know that your case system does not talk to your portal, or that your sales pipeline lives somewhere else entirely. They just know they cannot get an update without calling, emailing, or chasing someone who is already juggling three inboxes.
This is the boring argument for integration. Not as a shiny “digital transformation” programme, but as the quiet work of making information move through your business in a way that is fast enough to be useful, accurate enough to trust, and secure enough to sleep at night.
The patchwork itself is not a failure. It is a sign your business has been busy.
As you grow, you buy tools to solve immediate problems. You bolt on systems to keep up. You keep old things running because they are vital and nobody has time to replace them. You build a little bespoke app because nothing off-the-shelf quite fits. And somewhere along the way, spreadsheets become the duct tape holding it all together.
The problem is the tax you pay when those tools do not connect.
You pay it in re-keying. Sometimes it is a team of people dedicated to typing from one screen into another. More often it is individuals burning minutes at a time, all day, transposing data and copy-pasting “just this once” to keep things moving.
You pay it in duplication and doubt. When the same data exists in three places, you start to ask the wrong questions. Not “what should we do next?”, but “which one is right?”. That doubt slows decisions down and it makes good people feel like they are always behind.
You pay it in customer experience. If staff have to hunt for information, customers have to wait. If the right update is stuck in the wrong tool, customers chase you for it. If your status is not visible, your phones get louder.
And you pay it in reporting. Not because your people are bad at reporting, but because you cannot interrogate what you cannot trust. When data lands late, or arrives half-formed, you end up making decisions on instinct because the numbers are always a week out of date.
Here is a slightly blunt truth: when systems do not talk, your people become the integration layer.
They re-key, copy-paste, export, import, chase, and reconcile. Not because they enjoy it, but because the business still has to run.
Connected systems win because you stop paying humans to be the courier and the referee. Information shows up where it is needed, when it is needed, in a way that matches the rules of your business. Decisions get faster. Customers get updates without a phone call.
The catch is that integration is easiest to get wrong when you skip the boring first hour…
Spend that hour squashing the picture into your head: which systems hold the data that matters, which system is the source of truth for each key thing, and how information moves today (including the unofficial “someone emails a CSV” bits). That map will save you from costly mistakes and blind spots.
If you do not know where your data is, that is another problem entirely. Until you can answer that, any integration you build will be built on guesswork.
Once you have the map, the mechanics are just choices.
An “integration” can be someone re-keying a figure from a spreadsheet into finance. It can be an RPA bot clicking through a routine at 2am. It can be a nightly file export and import. It can be a web API. It can be reading from a database. It can be a message queue, pushing events around so systems can react in near real time.
Those are just the mechanics. Underneath them, there is always a process.
Something happens. Data needs to move. It needs to be transformed. Field names change. Two fields become one. One field becomes three. Some data must be redacted or restricted as it flows from one context to another. Exceptions appear. Someone needs to decide what to do when the data does not fit the norm.
I want to give you two examples that show how integration pays back without needing a full rip-and-replace.
They are different settings, different pressures, different volumes, but the pattern is the same: connect what you already have, make the flow reliable, and keep humans involved where the real world refuses to be tidy.
In one engagement, the problem was simple and human.
Customers were often stressed and needed reassurance. They wanted to know what was happening with their case. The organisation had a capable call centre with good people, but a large chunk of calls were effectively “can you tell me the status?”.
That is expensive in the obvious ways (time, staffing, queues). It is also expensive in the less obvious way: every status call interrupts staff who could be handling the cases that actually need conversation and judgement.
The underlying constraint was the familiar one. The core case management system was legacy. Vital, but not modern. No customer portal bolted on. No clean way for customers to self-serve updates.
The fix was not to replace the core. It was to add a safe layer around it.
We helped design and build a lightweight customer-facing web application, backed by a modern API sitting between the legacy database and new experiences. Authentication was handled without forcing customers to create brand-new accounts: customers provided their case reference and then received a short-lived SMS code, giving two factors (something they know, something they have).
The point was not tech for tech’s sake. It was to let customers get a secure status overview on demand, reduce unnecessary calls, and make the ROI measurable via call patterns and call duration shifts.
If you want the full write-up, it is here: Case Study – Case Status Self-Service
In another engagement, the integration was high-volume and operationally critical.
The client needed a new integration to replace an existing one while they were replacing a key back-office system. The goal was clear: automatically transform data between two large systems, but keep control in the hands of staff who understand the edge cases.
The solution was a centralised integration system with a web-based administration interface.
It processed more than 45,000 policy-related records each month. Most flowed through automatically. When something did not fit, the system did not quietly fail and leave someone guessing. It surfaced exceptions on a dashboard, allowed staff to maintain the mapping rules, and supported manual handling for the cases that could not be automated cleanly. Summary emails reported on state and linked directly to items needing attention.
This is what “human in the loop” should look like in practice. Not humans doing the boring parts, but humans handling the genuinely unusual situations with clear visibility and good tools.
If you want the condensed case study, it is here: Case Study – Tenet Group
When people talk about “systems projects”, they often picture replacement. A big programme. A big budget. A big switch-over.
Integration projects are different. The best ones start small and earn the right to expand.
If you connect two systems and remove a chunk of re-keying, you get time back immediately. If you make a status visible to customers, you reduce chasing immediately. If you automate a data handoff that used to depend on one person remembering the right sequence, you reduce risk immediately.
And because integration work sits at the edges, you can usually deliver value without taking the business offline. You are not asking everyone to learn a brand new way of working all at once. You are making the current way of working less painful, then progressively better.
That is also why this is a good place to start if you have been burned before. You can build trust with outcomes rather than promises.
Start by zooming out, then zooming in.
You zoom out just enough to see the landscape. Then you zoom in on one flow that hurts. Then you ship something small. Then you update your picture of the landscape based on what you learned. Then you repeat.
That is not indecision. That is how you reduce risk.
You do not need a perfect enterprise architecture diagram. You do need a rough map that answers a few basic questions:
If you want to sanity check your map, a good test is this: could you explain it to a new starter in ten minutes without waving your hands?
Integration is one of those areas where “strategic” can become an excuse to delay.
Pick the flow where the pain is obvious and the ROI is easiest to explain. The one that triggers re-keying every day. The one that creates the loudest customer chasing. The one that makes your reporting unreliable.
This is not about ignoring the big picture. It is about choosing a part of the picture that will create momentum.
There are plenty of ways to make data move. They are not all equal, and they are not all wrong.
Here is a pragmatic comparison to help you choose without overthinking it.
| Option | Use it when | Watch-outs |
|---|---|---|
| Manual re-keying | You need a stop-gap, the volume is low, and the process is stable | Errors, hidden cost, no audit trail, hard to scale |
| RPA (robot clicking) | There is no API and you need relief quickly | Brittle routines, poor error handling, security risks if done badly |
| File-based transfer (CSV, secure file drop) | You can tolerate batch updates and want simplicity | Latency, schema drift, awkward exception handling |
| API integration | You need speed, reliability, and clearer contracts | Requires good API design, versioning, monitoring |
| Message broker / event-driven | You have multiple integrations and want decoupling | Needs good operational discipline, tracing, and governance |
The best answer is often a mix. Sometimes a daily file drop is perfectly fine. Sometimes near real time is necessary. Sometimes the quickest win is replacing a single spreadsheet with a small app, not building an integration at all.
Most integration pain is not caused by the “happy path”. It is caused by the 3% of data that does not fit, and the lack of visibility when something silently fails.
These are the boring things that make integrations safe:
If you are not sure where to start, ask these:
- Where do we re-key the same data more than once a day?
- What is the single update customers chase us for most often?
- Which report do we not trust (and what data is missing or late)?
- Where does a process slow down because someone has to “go and check another system”?
- Which handoff would still hurt if we hired two more people?
A four-week starter loop (zoom out, then ship)
- Week 1: Zoom out and measure. Sketch the landscape, pick one painful flow, and estimate the time or call volume tied to it (rough numbers are fine).
- Week 2: Build the smallest useful bridge. Start read-only if possible: a dashboard, a status view, a synchronisation job, a notification.
- Week 3: Handle reality. Add validation, exception handling, and a way for humans to resolve the weird cases without chaos.
- Week 4: Prove it and decide. Monitor the impact, confirm the ROI, then either expand the same integration or pick the next flow.
If you want a few practical ideas to get moving, here are three that often land well.
Integration projects have risks. Anyone who tells you they do not is either inexperienced or selling something.
The first worry is brittleness. “What if it breaks when a system changes?” It can, which is why you design with contracts, monitoring, and clear failure modes. A brittle integration is usually a sign the hard work was skipped, not that integration is impossible.
Then there is cost. The trick is to treat integration as a series of value-earning slices, not a monolithic programme. If an integration does not deliver value quickly, stop and reassess. You are allowed to change your mind.
Security and compliance come up quickly too, and they should. Connecting systems does not mean exposing everything. It means controlling flows properly: least privilege, careful data minimisation, audit trails, and clear authentication. The “case status” example above is a good reminder that you can improve customer access while tightening controls, not loosening them.
And finally: “we have been burned before”. If that is you, start with something that can be turned off without drama. Read-only first. Small customer-visible wins. Short feedback loops. Trust is earned by outcomes.
Ask this question in your next ops meeting: “Where does data move slowly enough that we make worse decisions?”
Then choose one flow and fix it. Not perfectly. Just enough that you can feel the difference.
If you would like a second opinion, we offer a free system review consultation. It is a proper conversation, not a sales pitch, and we will happily tell you when we are not the right fit.
If you want something more structured to guide you, hit our contact form and ask for the SeriouslyRAD Modernisation Field Kit. We will send it over and help you use it to map your data landscape and prioritise integrate vs wrap vs replace.
Pete brings robust security expertise backed by his credentials as an Offensive Security Certified Professional (OSCP). With his strategic vision, Pete ensures our software architectures are secure and scalable, underpinning our clients' trust in our solutions.