A melting pot of systems: integrating AI when every site runs something different

Ask an operations director to list the systems across their sites and the answer usually comes with an apology. The main warehouse runs a modern system with an API. The site that came with an acquisition three years ago runs an older one that nobody wants to touch. A third runs a spreadsheet and a strong-willed supervisor. The apology is unnecessary. This is what most multi-site operations look like, and AI integrations are built for it.

The worry behind the apology is that AI needs one tidy system first, and that the first step is a company-wide replacement nobody has time for. It is not. The first step is to read from what is there.

Why every site runs something different

Operations grow by acquisition, by opening new sites in new regions and by surviving long enough for systems bought in different decades to run side by side. Each site chose or inherited a system that fitted it at the time. Each has habits, custom fields and workarounds built up over years, and each works well enough that replacing it is never the most urgent thing.

The result is a melting pot: two or three warehouse systems, more than one version of the same one, an order system from head office, a dock calendar in a spreadsheet at one site and inside the warehouse system at another. Replacing all of it with one system is a multi-year programme with its own risks, and it is not a precondition for AI.

APIs where they exist, a copy of the database where they do not

An integration needs to read orders, stock, appointments and whatever else the task needs, from each site. There are two common doorways.

The modern systems offer an API (the doorway other software uses to read from and write to a system). The integration asks for the orders of the day or the stock in an aisle and receives them in a form it can work with. Writing back, such as handing over a prepared order, goes through the same doorway, under the same permissions a person would have.

The older systems often have no usable API, but they have a database, and a copy of that database can be read. The integration does not lean on the live database that runs the floor; it reads a copy, kept current enough for the task, so the floor feels nothing. Where a site runs on spreadsheets or paperwork, the integration reads those as documents, the same way it reads a client email.

One integration that reads from each

The design pattern is one integration, one task, several sources. A late order risk alert, for example, needs the order book and the stock position from each site. At the modern site it reads them through the API. At the older site it reads the database copy. At the third it reads the shared spreadsheet. Each source is translated into the same handful of fields the alert needs, and everything after that point is identical.

• The translation is written once per system, not once per task. The second integration that needs orders from the older site reuses the first one's work.
• Each site keeps its own system, its own habits and its own version. The integration adapts to the site, not the other way round.
• Every row the integration reads is stamped with the site it came from, so a suggestion in the redfly Portal always says which building it is about.
• When a site does replace its system later, only that site's translation changes. The alert, the checks and the people using it carry on.

When several sites must be seen at once

Some tasks only need one site's data at a time. Others need to see across the company: a stock move suggestion between branches, a daily summary for head office, a grain position across every elevator. For those, the data from each site has to be brought together into one current copy before the AI can reason over it.

That is the work redfly's warehouse sync add-on does: a small service at each site sends changes outward into one central store, with every row stamped with its origin, over whatever link the site has. The AI integration then reads from the central copy, and it does not matter that the sites run different systems underneath.

Why this is normal, not a blocker

The melting pot is not a reason to wait. It is a reason to start with one site and one task where the doorway is already open, learn the shape of that site's data, and then add the next site through its own doorway. Each addition is work, and it is ordinary work: a database account, an API key, a mapping of fields. None of it requires anyone to stop using the system they rely on today.

The honest caveat is that the first site is the easiest and each old system adds some effort. That effort is bounded and visible, and it is far smaller than the replacement programme people fear is the alternative.

AI does not need one system to rule your sites; it needs a doorway into each one, and every system has one.

This is how redfly approaches multi-site operations: one integration woven into the systems each site already runs, reading through the API where there is one and a copy of the database where there is not, with warehouse sync bringing the sites together when a task needs to see them all, and the results landing in the redfly Portal.