Automation without replacing systems: what middleware can do
14 May 2026 · David Sak · 5 min read
"First we need to replace the ERP, then we can talk about automation." I hear this sentence often, and it's almost always a mistake that costs the company a year of time and millions extra. In most cases the problem isn't the systems, it's that people are the ones carrying data between them.
What middleware is
An integration layer that sits on top of your existing systems and carries data and events between them. The ERP, CRM, warehouse and accounting don't change, they just get a shared "nervous system". When an order appears in the e-shop, the middleware validates it, creates it in the warehouse, generates the invoice and sends a notification, without a single manual re-type.
Event-driven: reacting to events, not overnight batches
Older integrations worked in batches, an export transferred once a night. Modern orchestration reacts to events in real time: a shipment loaded, a payment received, a status change. The difference shows in the numbers; in the model case of a logistics company (covered in my case studies) this approach cuts order processing from 48 hours to 11 minutes, without changing a single one of the three systems.
"But our system has no API"
If a system has no API, an RPA layer is deployed, a robot that works with the system through its interface like a human would: reading screens, filling forms. It's less elegant than an API and I say so honestly: RPA is a bridge, not the target state. But it works reliably, deploys in days, and unblocks automation where you'd otherwise wait years for a system replacement. Once an API appears, the layer gets swapped, the rest of the pipeline stays.
Where the limits are
- Middleware won't fix data chaos. If three systems keep three different customer registries, the integration first needs mapping and deduplication. It's doable, but it must be part of the design.
- An extremely unstable system, if the ERP crashes twice a week, automation only accelerates the instability. Stabilize first, orchestrate second.
- Processes nobody knows. You can only automate a process you can describe. That's why every deployment of mine starts with an audit, not code.
When replacing the system does come first
The honest answer: when the system is failing at its own job, not at integration. You've outgrown license limits, the vendor is ending support, features the business needs are missing. Then replace it. But replacing a working ERP just "so it integrates better" is the most expensive possible path to automation.