Your WMS probably isn’t the problem.

When picks are slow, counts drift and operators are working around the system instead of through it, the instinct is to blame the platform and start pricing a replacement. In the great majority of cases that is the wrong diagnosis. The WMS is doing what it was configured to do — the configuration has simply drifted from how the floor actually operates. Pick and put path logic, slotting, wave planning, directed put-away, allocation, batching and replenishment rules are all things you set, not things the platform imposes on you, and they degrade quietly as SKU counts grow, order profiles shift and processes change underneath a setup nobody has revisited since go-live. Before a replacement conversation starts, the configuration is the first place to look, because it is very often the whole answer.

Why the WMS gets blamed for a configuration problem

A warehouse under strain produces symptoms that look platform-level: throughput that never matches the rated numbers, exceptions that pile up faster than anyone can clear them, and operators quietly building spreadsheets and paper workarounds because the system’s directed logic does not match how the building actually flows. Those symptoms are visible and painful, and the platform is the thing everyone can see and name, so it takes the blame. What is usually invisible is the accumulated drift underneath: slotting that reflects last year’s velocity, wave logic tuned to a labour model that changed, put-away rules that were never adjusted when a new receiving process went live. None of that is a defect in the software. It is a gap between the system’s configuration and the floor it is meant to serve, and gaps like that are closed by reconfiguring, not by re-platforming.

The cost and risk of rip-and-replace

Replacing a WMS is one of the largest operational risks a warehouse leader can take on. A migration means re-mapping every integration to your ERP, carriers and automation, re-training every operator on new screens and logic, and running a cutover that puts live throughput at risk during go-live and stabilisation. It is typically a multi-quarter programme with a meaningful capital and licence commitment, and none of that spend touches the underlying process design — the new platform can be configured just as poorly as the old one if the same drift is carried across unexamined. Replacement is sometimes genuinely the right call, but it should be a decision made after the configuration has been assessed, not instead of assessing it. Spending months and a significant budget to solve a problem that a few weeks of reconfiguration would have fixed is the most common and most avoidable cost in warehouse technology.

The cost and lower risk of optimisation

Optimisation works inside the platform you already run and already know. There is no re-mapping of integrations, no wholesale re-training, and no cutover risk, because the system operators use today is the same system they use tomorrow — only its logic is better aligned to how the floor actually moves. The work is staged: a KPI baseline is set across receiving, put-away, picking and shipping, changes are made and validated against that baseline in sequence, and go-live and rollback criteria are agreed before anything touches live operations. That staging is what keeps the risk small — each change set is measured, not deployed as a single high-stakes cutover. The timeline is measured in weeks, not quarters, and the spend is a fraction of a replacement programme, because the underlying platform, its licences and its integrations are all untouched.

When optimisation wins

Optimisation is the right call when the symptoms trace back to how the system is configured rather than what it is capable of. That is true more often than warehouse leaders expect. Look for these signals:

• Picks running slower than rated throughput, with no clear hardware or labour cause — usually a pick-path or slotting problem.
• Operators building workarounds — spreadsheets, paper pick lists, manual overrides — instead of following system logic, which means the logic no longer matches the work.
• A configuration that has drifted since go-live, with no one able to say when slotting or wave rules were last reviewed against current volume.
• Growth that has outpaced the original setup — new SKUs, new order profiles, a new building — layered onto rules designed for an earlier state of the business.
• The platform has the functional capability you need — directed put-away, waving, batching, returns disposition — but it is not switched on or tuned for your operation.

Where those hold, reconfiguration closes the gap directly, at a fraction of the cost and risk of a migration.

When replacement is genuinely warranted

Replacement earns its cost when the limitation is structural, not configurable. That includes a platform that architecturally cannot support the automation, integration volume or order complexity the business has grown into, no matter how it is tuned; a vendor that has stopped supporting or developing the version you run, leaving you exposed on security and compatibility; licensing or contractual terms that no longer fit the scale of the operation; or a genuine functional gap — a capability the platform simply does not have and cannot be configured to have. In each of those cases, no amount of pick-path or slotting work will close the gap, because the constraint sits below the configuration layer, in the platform itself. The distinction matters: configuration problems are solved by reconfiguring; platform problems are solved by replacing the platform. Confusing the two in either direction is expensive.

How to tell which one you have

The honest way to answer this is to assess before deciding. A short, independent review of your pick logic, slotting rules, wave strategy and put-away configuration against a current KPI baseline will show whether the symptoms trace to configuration drift or to a genuine platform ceiling. That assessment is cheap relative to either a reconfiguration project or a replacement programme, and it removes the guesswork from a decision that otherwise gets made on instinct and vendor pressure. 1722 does not sell a WMS, takes no vendor commissions, and has no stake in which answer the assessment produces — the recommendation follows what the system and the floor actually show, not a platform to sell you.