How to centralize warehouse data from every site without replacing what runs the warehouse

The question head office asks is simple: how many orders shipped from every site today, and how many are still waiting? The reason it is hard to answer is not the arithmetic. It is that each warehouse runs its own warehouse management system (the software that tells people what to pick, pack and ship), on its own server, in its own building, and none of those servers know the others exist.

The instinct is to fix this by standardizing: one system, one database, every site. That is a multi-year program with real risk to the operation, and most of it produces no new revenue. There is a less disruptive shape, and it starts from a different assumption: the warehouse system is fine where it is.

Leave the warehouse alone

The system that runs the floor was chosen, tuned and trusted over years. The people on the floor know its screens. The scanners talk to it. When it stops, trucks wait, so nobody with operational responsibility wants to swap it out to get a better report.

So the first rule of centralizing is that nothing at the warehouse is replaced or rewritten. The warehouse management system stays. Its database stays. The version stays. All that is added is a small service, installed on a machine inside the site's own network, next to the database it already runs.

What the small service does

That service watches the tables you choose, the ones head office actually needs: orders, shipments, inventory movements, whatever matters for the reports. When a row in one of those tables is added, changed or deleted, the service notices, queues the change on site, compresses it, encrypts it with that site's own encryption, and sends it outward to a central store in your cloud account.

Outward is the important word. The service opens connections from inside the site to the outside and never the reverse. Nothing reaches back in, and the central store never writes anything to the warehouse database. The flow is one direction, site to center.

After an initial copy of the chosen tables, only what changed leaves the site. A busy warehouse sends a steady trickle of small changes, not a fresh export of the whole database every night.

What changes for the head office

Every site's changes land in one central store. Each row is stamped with the site it came from, and each site keeps its own space in that store, so a row from the Texas depot is never confused with a row from the Georgia one. The central copy is current to within a couple of minutes of what the warehouse database holds.

That is what your reports read. A dashboard, a scheduled export, a regional manager's morning view, a customer's tracking portal; all of them point at the same central copy, not at thirty separate warehouses. The numbers agree because they come from one place.

The practical difference is who does the waiting. Today, head office waits for somebody at each site to run an export and send a spreadsheet, then waits again to find out why two spreadsheets disagree. With a central copy, the question of how many orders are still waiting has one answer, and it is a few minutes old rather than a day old.

Your team builds those reports and any portal. We advise on the shape of the data and supply tools to build against it, but the reports are yours, in whatever reporting tool you already use.

What does not change for the floor

The floor should notice nothing. The warehouse system behaves exactly as before, because it has not been touched. The pickers use the same screens, and the scanners hit the same database.

Two details keep that promise honest. First, the service holds back when the site's machines are busy; it is a guest on that server and behaves like one. Second, reports run against the central copy rather than the warehouse database, so the reporting queries that used to compete with picking and packing are gone from the onsite server entirely. That leaves the warehouse server with more headroom than it had before, which is what keeps it steady through a peak.

If the internet link drops, the service keeps queuing changes on site and sends them when the link returns, resuming table by table from where it stopped. The floor does not notice that either. The onsite queue is a holding queue for outbound changes, nothing more; it is not a copy the warehouse can read from while cut off.

Rolling it out

Each site needs its own setup. A person from our side, with your one IT contact, installs the service, chooses the tables, and runs the first sync (the initial copy of the chosen tables). It is the same rollout every time rather than a fresh build, but it is still work done by a person, not a switch you flip. Adding a table later is a setting change, and again someone does it.

We recommend starting with one site and one set of tables, getting something useful into the hands of head office early, and then rolling out at your own pace.

The warehouse keeps running its own system; the head office finally gets to see all of them at once.

redfly builds and runs this service with logistics companies as design partners, starting with a single site on SQL Server, MongoDB or Postgres.