Making new systems work with the ones you already have

Few organisations start from a blank sheet. A new warehouse system, sensor network or customer portal arrives in a business that already runs an ERP, a finance package, spreadsheets that someone depends on, and equipment on the floor with its own controllers. The value of the new system depends less on its feature list than on how well it exchanges data with what is already there.

Our view is that integration should be designed at the start of a project, not left to the end. This is how we approach it.

Choose the pattern that fits the flow

There is no single right way to connect systems. The right pattern depends on how fresh the data must be, how much of it there is and what the other side can support.

• APIs: one system asks another for data, or asks it to do something, and gets an answer straight away. REST APIs suit lookups and actions that a person is waiting for.
• Webhooks: a system notifies another when something happens, such as an order being dispatched, so nobody has to keep asking.
• Message queues: events are placed on a queue and processed in order, even if the receiving system is busy or briefly unavailable. MQTT brokers play a similar role for device data.
• File exchange: scheduled CSV or XML files over a secure transfer. Unfashionable, but often the only option an older system offers, and perfectly adequate for daily batches.
• Industrial protocols: Modbus, OPC UA and BACnet connect controllers, meters and building systems. A gateway usually translates them into something the IT side can use.

Most real projects use several of these at once. What matters is that each flow has a clear owner, a documented format and a defined behaviour when something goes wrong.

Decide who owns each piece of data

Integration problems are often ownership problems in disguise. If the ERP and a new warehouse system can both change a product's dimensions, they will eventually disagree, and nobody will know which one is right.

For each important record, name a single system of record: the place where it is created and changed. Other systems read it, copy it or add to it, but do not overwrite it. Stock levels, customer details, prices and storage locations each need an answer. Writing these decisions down early prevents a slow drift into duplicated, conflicting data.

Ownership also covers access. Agree who may read what, how credentials are issued and rotated, and what happens to the data if a supplier relationship ends.

Start with one high-value flow

The temptation is to connect everything at once. A better first step is to pick the single flow that causes the most manual work or the most errors today, and automate it well.

In a warehouse, that might be receiving purchase orders from the ERP so goods can be checked in against them. In inventory, it might be sending stock levels from shelf sensors back to the purchasing system. One working flow proves the connection, exposes the real quality of the data and gives the people involved a reason to trust the next step.

Avoid the big-bang replacement

Replacing a core system in one go concentrates all the risk into a single cut-over weekend. If anything goes wrong, operations stop, and rolling back is rarely clean. An incremental approach is slower on paper but safer in practice:

1. Put a clear interface in front of the old system, so new components talk to the interface rather than to the old system's internals.
2. Move one function at a time behind that interface to the new system.
3. Run old and new side by side where possible, and compare their results.
4. Retire the old component only when the new one has carried real work for long enough to be trusted.

This keeps the business running throughout. Each step can be paused or reversed without undoing everything else, and the team learns the new system gradually rather than all at once.

Test and monitor integrations like products

An integration that worked on the day it went live can fail quietly months later. A field is renamed, a certificate expires, a supplier changes a format, a nightly file stops arriving. Because the failure sits between two systems, neither team may notice until someone asks why the numbers look wrong.

Treating each integration as a small product, with its own tests, monitoring and owner, keeps it reliable over time:

• Contract tests that check each side still sends and accepts the agreed format.
• Test environments with realistic data, including the awkward cases: missing fields, duplicates and very large batches.
• Retries with sensible limits, and a holding area where failed messages wait to be inspected and replayed rather than being lost.
• Dashboards and alerts on volumes, delays and errors for each flow, with a named person responsible for responding.

A LIOMO project typically treats integration as part of the system rather than an afterthought: mapping existing systems and data owners, building the connectors and gateways, and monitoring each flow after go-live, so that problems surface on a dashboard rather than in a customer complaint.