"Do I need to replace my WMS to use AMRs?" is the first question most UK third-party logistics operators ask, and the honest answer is no for the large majority of sites. A fleet management layer sits above the warehouse management system and takes work from it, so the WMS stays the system of record for stock and orders. The sector has reason to look hard at automation: HSE counts 40,000 transport and storage workers suffering non-fatal injuries a year, averaged over 2022/23 to 2024/25 (Transportation and storage statistics in Great Britain, 2025). For a supply chain director in contract logistics, though, the blocker is rarely the robot. It is the fear that a client-mandated WMS, written into a three-year contract and shared by four customers on one site, will have to be torn out to make room for mobile robots. That fear stalls more business cases than payback figures ever do, and it is usually unfounded.
Why the replace-the-WMS myth persists
Three things keep this myth alive, and none of them is technical inevitability.
The first is history. Early automated guided vehicle projects shipped with their own closed control software, which expected to own task allocation, locations and often stock itself. Buying that meant accepting a second source of truth, and the cleanest fix was to let the new system take over. Plenty of people running UK distribution centres today formed their view of automation during exactly that period.
The second is vocabulary. Warehouse management, warehouse execution and fleet management get used as if they were the same product. They are not. A warehouse management system holds stock and decides what work is needed. A warehouse execution layer sequences and prioritises that work in real time. A fleet manager is the robot-side layer that turns each task into routes, traffic rules and vehicle assignments. When a supplier says their software "manages the warehouse", a director hears "replaces the WMS", and the quote starts to look like a systems programme rather than a materials handling purchase.
The third is data quality, wearing a disguise. Where locations are not uniquely identified, or stock balances are only trusted after a shift-end count, automation exposes the gap immediately. It is tempting to read that as a failure of the system, when it is almost always a failure of the master data inside it, and a new system inherits the same records. Fixing identification discipline is cheaper and reversible, which is why robot to WMS and ERP integration work normally starts with a data review rather than a software selection.
A fleet management layer sits above the warehouse management system and takes work from it, so the WMS stays the system of record for stock and orders and does not need replacing.
Lever one, operational: start from the flow, not the system
Pick the single highest-volume move on the site and describe it as work rather than as software. For a contract logistics operation that is usually inbound pallets from the dock to a bulk location, or replenishment from bulk to pick face. Write down what triggers the move, who decides priority, what identifies the load, where it must arrive, and who needs to know it happened. That list is the interface specification, and it is normally five to eight fields.
Once the flow is written down, the question changes from "can our WMS run robots" to "can our WMS tell us these five things and accept one confirmation back". Most can, including systems well over a decade old. Scoping a first flow this way also caps commercial exposure: you are buying an interface for one movement type, not a platform migration.
Lever two, technical: put a fleet management layer in the middle
The fleet manager is what makes keeping your existing WMS possible. It receives a task, decides which vehicle takes it, plans the route, arbitrates traffic between machines, manages charging windows, and reports acceptance, progress, completion and exceptions. Detailed telemetry such as battery state and fault codes stays in the fleet layer and is summarised upward.
Underneath, VDA 5050 gives one fleet manager a common message format for vehicles from different manufacturers, which is what allows a mixed estate to grow without a bespoke integration for every machine. Above, the connection to your warehouse system can be a live interface or, where none exists, a scheduled export and import handled by middleware that deals with translation, retries and duplicate suppression. Both patterns are routine. We covered the message content in detail in what data a robot fleet exchanges with an ERP, and the mixed-estate case in can a multi-vendor robot fleet run in one warehouse.
Lever three, regulatory: your safety case does not live in the WMS
This matters because it removes the WMS from the critical path entirely. Mobile robots in a British warehouse are work equipment, so the Provision and Use of Work Equipment Regulations apply: suitable equipment, suitable for the conditions, properly maintained, used by trained people. The full text sits on legislation.gov.uk, and LOLER 1998 sits alongside it wherever loads are lifted. ISO 3691-4 covers driverless industrial trucks and their systems, and the HSE workplace transport guidance frames the pedestrian separation question that dominates most risk assessments.
None of that is satisfied or compromised by your choice of warehouse software. Protective device coverage, speed zoning, aisle widths, floor condition against TR34 tolerances, charging area ventilation and the written safe system of work are the deliverables, and they are assessed on the vehicles and the building. A WMS replacement adds months to a project without moving a single one of those items forward.
Lever four, commercial: scope the interface in the contract
Contract logistics has a complication a single-user site does not: the WMS is often the client's, hosted by the client, and changed on the client's release schedule. Robots do not change that, but the interface has to be written into the agreement. Agree who builds each side, what the test environment is, how exceptions reach your shift managers, and who pays for change when the client upgrades. Sites around the UK logistics corridors such as Magna Park, DIRFT and Daventry routinely run multi-client operations where this is settled on paper before any order is placed.
| Route | Typical time to first live flow | Relative cost | Main risk | When it is the right call |
|---|---|---|---|---|
| Keep the WMS, add a fleet manager with a live interface | Weeks, once data access is granted | Lowest | Interface scope creeps if the flow is not written down first | The WMS exposes open work and accepts confirmations. The default for most sites. |
| Keep the WMS, use scheduled file exchange plus middleware | Weeks, with timing rules to agree | Low to moderate | Latency and duplicate handling need explicit rules | The system has no documented interface and cannot be modified. |
| Replace the warehouse management system | Months to a year, before robots start | Highest, and usually a separate programme | Automation payback is deferred behind a systems migration | The system genuinely cannot expose work at all, or replacement was already funded for other reasons. |
What FlyWei does here
FlyWei is an independent, vendor-neutral UK systems integrator of autonomous forklifts and AMRs, which means the answer to this question is not shaped by a software licence we need to sell. FlyWei starts by reading the flow and the data, not the system name. Where the existing warehouse system can expose open work, FlyWei builds the interface to it and leaves it as the record of stock. Where it cannot, FlyWei designs a scheduled exchange with middleware that handles translation, retries and duplicate suppression, so the first flow still goes live this year rather than behind a migration.
On the robot side, FlyWei integrates the best machines across multiple manufacturers for the task in hand: FlyWei autonomous forklifts for pallet moves from dock to bulk, narrow-aisle reach and stacker classes for high-bay replenishment, and latent-jacking AMRs where cages and trolleys are the unit of movement. The M4 fleet manager and the robot dispatch software sit between those machines and your warehouse system, arbitrating traffic, charging and priority across a mixed estate. The practical effect is that automation becomes a flow-by-flow decision taken inside a customer contract, not a systems programme needing board approval first. FlyWei supplies the vehicles, the integration and the warehouse automation solutions around them as one scope.
Frequently asked questions
Do I need to replace my WMS to use AMRs?
Usually not. A fleet management layer sits above the warehouse management system and takes work from it, so the WMS stays the system of record for stock and orders. Replacement is only worth considering where the system cannot expose work through an interface or a scheduled export, and even then middleware is normally cheaper.
What if our warehouse system has no API at all?
File-based exchange still works. A scheduled export of open orders and an import of confirmations is often enough to begin, with middleware handling translation, retries and duplicates. It is slower than a live interface and needs clear timing rules, but it avoids modifying the core system.
Who owns the interface when the client owns the WMS?
Agree it in writing before ordering vehicles. Name who builds each side, which environment is used for testing, how exceptions reach your shift team, and who funds change when the client upgrades. In multi-client sites this clause matters more than the robot specification.
What is the difference between a WMS, a WES and a fleet manager?
A warehouse management system holds stock records and decides what work is needed. A warehouse execution system sequences and prioritises that work in real time. A fleet manager is the robot-side layer turning each task into routes, traffic rules and vehicle assignments. Smaller sites often combine the last two.
How do stock balances stay accurate if the WMS is not controlling the robots?
Each completed move sends a confirmation naming the load, the location it left and the location it reached. Your warehouse system posts that as a stock movement, so balances update as pallets move rather than at a shift-end count. Failed or abandoned moves must raise an exception rather than post silently.
Does adding robots to our warehouse system create a security exposure?
It creates a link between operational and business systems, so design it like any other. Segment the robot network, limit the integration account to the fields it needs, log all traffic and control supplier remote access. IEC 62443 zones and conduits are the usual reference.
How long does a first flow take to go live?
It depends far more on data access than on the vehicles. Commissioning is rarely the long pole. Mapping order and stock fields, agreeing exception handling and testing against live data are. Projects move fastest where the existing system already exposes a documented interface and a test environment is available.
If a client-mandated WMS is the reason robot automation keeps slipping down your Q4 risk register, the fastest way to settle it is to test one flow rather than debate the platform.
Get a 48-hour feasibility read on your highest-volume flow, and we will tell you plainly whether your existing system can feed it as it stands. If it can, the M4 fleet manager does the rest without touching your stock records.
No obligation, and we reply within one business day.