Every operations director eventually faces the same crisis: the CRM does not talk to the billing system, the billing system does not talk to fulfillment, and a small army of people is copy-pasting between tabs to keep them all roughly in sync. The instinct is to rip everything out and replace it with one mega-platform. Usually that is the wrong instinct.
Why “one platform to rule them all” rarely works
A consolidation play replaces three good-enough systems with one system that is mediocre at three things. Your sales team loses the CRM they actually use, your accountant loses the billing tool your books are built on, and your warehouse loses the workflow it has refined for years — all in exchange for a platform whose main virtue is that it is singular.
It also demands a multi-year migration during which both versions of the truth coexist, which means the copy-paste problem you were trying to kill gets worse before it gets better. It hands you a single vendor lock-in profile that is harder to negotiate than three smaller ones. And it usually does not address the actual problem, which is data flow, not data location. Your systems do not need to live in one place; they need to agree with each other automatically.
What we build instead
In most integration engagements we build a thin custom middleware layer that owns three jobs.
A canonical data model
One representation of “customer,” “order,” “invoice,” and “shipment” that the middleware enforces. Each downstream system maps to and from it. No more arguments about which CRM field is the right one, and no more silent divergence where billing thinks the customer is Net 30 and the CRM thinks they are Net 60. When a new system joins the stack later, it maps to the canonical model once, instead of negotiating separate agreements with every existing system.
Event routing
When a sale closes in the CRM, the middleware fires the events that create the invoice, allocate inventory, and schedule the fulfillment. No human copy-paste, and no fragile point-to-point integrations that break the next time a vendor changes their API. Point-to-point is the trap here: three systems wired directly to each other is three connections, but five systems is ten, and every vendor API change ripples through all of them. With a hub in the middle, each system has exactly one connection to maintain.
Audit trail and reconciliation
Every event is logged. Every cross-system discrepancy is detected and surfaced instead of discovered three weeks later when a customer calls about an invoice for an order that never shipped. The middleware is the source of truth about what the source of truth should have been — and when something does go wrong, you have a timestamped record of exactly which system said what, when.
Built well, that layer is usually 4,000 to 15,000 lines of code — small enough that one engineer can hold the whole thing in their head, big enough to replace months of manual reconciliation work permanently.
“Can’t we just use Zapier?”
Sometimes, yes. Off-the-shelf automation tools are genuinely good at low-volume, low-stakes connections: a form submission creating a CRM contact, a closed deal posting to a channel. If that is the whole problem, buy the subscription and move on.
The tools run out of road when the workflow has state. Partial shipments, refunds against multi-line invoices, credit holds, an order edited after it was invoiced — these need a system that remembers what already happened and can reconcile disagreement, not a pipeline that fires once and forgets. They also run out of road on volume pricing and on debuggability: when a no-code automation silently fails at 2 a.m., there is no audit trail to reconstruct what should have happened. The honest rule of thumb: if a failed sync costs you real money or a customer relationship, the connection deserves real software.
What an engagement actually looks like
Integration projects reward starting small. We begin with discovery: mapping how an order actually moves through your business today, including the informal spreadsheet steps nobody documented, and identifying the one or two flows where manual reconciliation hurts most. Then we build the middleware around those flows first — typically getting the first automated flow into production within our standard 8 to 16 week window — and expand from there. Weekly demos keep your operations people in the loop, which matters, because they are the ones who know that the “shipped” status in the ERP does not always mean shipped.
This is the core of our integrated business systems practice, and it pairs naturally with legacy modernization: the same middleware that connects your CRM to billing can wrap an aging ERP behind a clean API, a pattern we describe in modernizing legacy ERPs without ripping everything out. Often the middleware also grows a thin web interface on top — an operations dashboard showing every in-flight order across all systems — which is where our custom web application work and our integration work meet.
The signal to act
Watch for these in your own operation: an employee whose actual job description is re-keying data between systems; a month-end close that takes days because three systems disagree; customer-facing errors that trace back to a stale record somewhere; or growth plans that stall because “the systems can’t handle it.”
If your team is currently running on a tab-juggling routine, the answer is almost never another platform purchase. It is the small piece of custom infrastructure that makes the platforms you already paid for actually work together. If you want a sanity check on whether your particular tangle is a middleware problem or genuinely a replacement problem, that is a conversation we have often, and the first 30 minutes are free.