ERP Integrations: The Middleware Layer Decides Everything
ERP Integrations: The Middleware Layer Decides Everything
An ERP is never the only system. It sits among a CRM, an e-commerce platform, a warehouse system, accounting software, payroll, and whatever bespoke tooling the business has accumulated. The ERP itself is usually fine. The connections between it and everything else are where projects come apart.
Point-to-Point Doesn't Scale
The default approach is direct integrations: ERP to CRM, ERP to storefront, CRM to storefront. Each is straightforward in isolation. Collectively they form a web where every new system multiplies the connections, and where one API change forces edits in several places at once.
A middleware layer inverts this. Systems talk to the integration layer, not to each other. Adding a system means one new connection rather than several, and swapping a vendor touches one adapter instead of rewriting half the estate.
Decide Where Truth Lives
The most damaging integration failures are not technical, they are definitional. Two systems both believe they own the customer record. Both accept edits. Both sync. The data diverges quietly for months.
Every entity — customer, product, order, inventory position — needs one designated system of record, with every other system holding a read-only reflection. This is an organisational decision as much as a technical one, and it needs to be made explicitly and written down.
Sync Timing Is a Business Question
Not everything needs to be real time. Inventory for a high-turnover storefront does. Financial reconciliation to the general ledger usually does not, and forcing it there adds cost and fragility for no operational benefit. Match sync frequency to how quickly a stale value actually causes harm.
Design for Failure, Because It Will Fail
APIs time out, rate limits trigger, records arrive malformed. An integration without retry logic, dead-letter queues, idempotency keys and alerting will silently drop transactions, and the business will discover it during a month-end close.
Idempotency deserves particular attention: retried operations must not create duplicate orders or double-post journal entries.
Make It Observable
Operations teams need to answer "did this order reach the warehouse?" without escalating to engineering. A dashboard showing sync status, queue depth, recent failures and retry state converts a category of urgent tickets into self-service.
Migration Is Not the Finish Line
Go-live is when integration work begins in earnest. Volumes shift, edge cases surface, connected vendors change their APIs. Budget for ongoing integration maintenance from the start rather than treating it as a project that ends.
Buy the ERP for its functionality. Win or lose the project on the seams.
Related Service
Explore how we deliver ERP Integrations