You haven’t written down what your WMS does
Should we just rip it out and start again? If you run a warehouse business, or you sell software to people who do, you have heard someone say that out loud in a meeting where everybody was tired. It tends to arrive after a peak season that went badly, or the week after the one engineer who understood the receiving module handed in their notice. I have heard it from customers more times than I can count over the last six years, and I said a version of it once about my own product, so I am in no position to sneer.
So this is where I’ve landed. You cannot make a good call between modernizing a warehouse management system and replacing it until somebody has written down, in plain sentences, everything the current system does, including the things nobody ever asked it to do. Almost nobody does this. It is tedious, and nobody is selling it, so replacement starts to look like permission to skip it. That is exactly backwards. The replacement path needs this list more than any other, and writing it honestly is often what tells you replacement was never the answer.
The old system is doing jobs nobody assigned it
Some context on where I’m standing. My company is fourteen people. We build returns software, the bit that sits between a shopper printing a label and a warehouse worker deciding whether the thing that came back can be sold again. To do that we integrate with whatever warehouse system the customer runs, which means I have spent a strange amount of my life reading other people’s WMS data and wondering why it looks the way it does.
A few years ago one of our customers, a third-party logistics company with two buildings and a lot of fashion clients, replaced a WMS that had been running for about fifteen years. They did it properly by most standards. They wrote requirements, ran a selection process, hired an implementation partner, trained staff, picked a quiet month for cutover. Two weeks after go-live, our integration started receiving returns for SKUs that did not exist in the new system’s item master.
It took us three days to work out why. The old WMS had a nightly job, written by a contractor long gone, that merged duplicate SKUs. One of the 3PL’s biggest clients had a habit of resending its whole catalogue every season with slightly different casing and the odd trailing space, and the old system had been quietly folding those duplicates together every night for the better part of a decade. Nobody listed it in the requirements because nobody knew it existed. It was never a feature. It was scar tissue.
The second surprise came a month later and cost more. The old system refused to let anyone pick from a location while a cycle count was open on it. The floor supervisor relied on that without ever thinking about it; it was simply how the building worked. The new system allowed it, as most do by default, and stock counts started drifting in the zones that got counted most often. Their inventory accuracy went backwards in the exact places they had been working hardest to protect it.
Both were behaviours of the old system that had become load-bearing without anyone noticing. Every long-lived WMS has dozens of them. Some live in code, some in batch jobs, some in a stored procedure someone added at 2am during an outage, and some exist only because the software makes one wrong action slightly awkward, so people stopped doing it.
Requirements documents capture what people know they want. They almost never capture what the system does that people have stopped noticing. That gap is where replacement projects bleed, and it is invisible right up until cutover, which is the most expensive moment to discover anything.
Writing it down is cheaper than either path
What I’m proposing is unglamorous. Before anyone talks to a vendor, before anyone prices a refactor, one person spends a couple of weeks building a single document called something like “Things the WMS does”. Every entry is a sentence in the form “when this happens, the system does that”. When a pallet is received against a closed purchase order, the system holds it in a quarantine location. When a pick is short, the system releases the next order in the wave rather than waiting. When a client’s catalogue arrives, the system merges SKUs that differ only by case.
You build it from three sources. The first is the floor. Sit with each area for a full shift, receiving and putaway and picking and packing and returns, and ask people to narrate what they do and what the screen does back. Pay particular attention to the moments where they reach for paper or a spreadsheet, because every workaround is a description of something the system fails to do, and every place they don’t need one is a description of something it does well. I didn’t invent that test. Aimprosoft’s piece on choosing between WMS modernization and a new implementation asks the same question of warehouse and IT teams, where people lean on spreadsheets and repeated checks, and it’s a sensible map of the options once you have this list in hand.
The second source is the code and the scheduler. Whatever runs on a timer, whatever triggers on insert or update, whatever a long-departed contractor bolted on. You don’t need to understand every line. You need a sentence per job saying what it changes and why somebody once cared.
Get Vlad Koval’s stories in your inbox
Join Medium for free to get updates from this writer.
The third is the person. Most warehouses have one or two people who carry the system around in their heads, and you already know who they are. Book them for two afternoons and ask what breaks when they’re on holiday. Write down every answer, even the ones that sound trivial. The trivial ones are usually the nightly SKU merge.
Then go through the list once and mark each entry as one of three things: the business needs this, the business tolerates this, or this is hurting us. That last pass is the only part that requires judgment, and it is where operations and engineering should argue, preferably in the same room.
I’m cheap by temperament, so here is how I think about the cost. A couple of weeks of one competent person’s time is the smallest line item in any WMS project you could name. Modernization projects run for months. A full implementation for a midsize operation is commonly quoted at four to nine months. The list costs less than a single week of either, and it is the one piece of work that is useful whichever way you go.
The list usually makes the decision for you
This is the part that surprised me the first time I watched a customer do it. Once the document existed, the modernize-or-replace argument mostly stopped being an argument. The answer was sitting in the shape of the list.
If the “hurting us” entries cluster in one place, say pick confirmation still happens on clipboards and gets keyed in at a desktop terminal later, you are looking at a modernization job. The system knows where the stock is. It just has a slow, error-prone way of hearing about what happened to it. Put a scanning interface in front of it and leave the core alone. Replacing a WMS to fix the way pickers report back is like moving house because the doorbell is broken.
If the trouble sits in one module with a clear edge, shipping being the classic case, a partial replacement starts to make sense. Now the list does a second job. It tells you exactly what the boundary between the old system and the new tool has to carry, because you have already written down what the old shipping logic did, including the strange parts. Without the list you discover that contract in production, one failed label at a time.
And if the trouble is spread across the whole thing, especially if half the entries trace back to some early assumption baked into the data model, then replacement is probably right. Aimprosoft’s piece has a good example of this: a system designed for one warehouse whose data model cannot distinguish inventory by location. No amount of tidying fixes that. But now you are replacing with a full account of what you’re leaving behind, which is the single most useful thing an implementation partner can receive on day one. The requirements document they get from you becomes an inventory of obligations, each one marked keep, change, or drop.
The list also shows you which risk you’re managing. When I look back at the customers who got through this well, what I learned to look at was how many entries on the list came from one person’s memory. If most of the behaviour you depend on lives in one engineer’s head, that is your real exposure, and it does not go away when you buy new software. It just moves to whoever configures the new one.
The strongest case against all this
The best objection I’ve heard came from a COO at a mid-sized fulfillment company, during a call where I was making roughly this argument at her.
“If I document every quirk of the old system, I’ll end up rebuilding the old system. Half the reason to replace it is to stop doing things the way we did in 2011.” — Renata Kowal, COO, a mid-sized fulfillment company
She is right about the danger. There is a real failure mode where the archaeology turns into a specification, and the new system gets customized until it behaves exactly like the old one, at what I’d guess is two or three times the cost and with none of the vendor’s upgrades still working. Standard processes in a modern WMS exist because thousands of warehouses have converged on them, and adopting one you didn’t choose is often healthier than preserving one you did choose fifteen years ago for reasons nobody remembers. A good chunk of any honest list should be marked “drop”, and some teams will lack the discipline to mark it that way.
She is also right that sometimes the list is a luxury. If your vendor has ended support, if the system has an unpatched security problem, if it runs on hardware you can no longer buy parts for, you are replacing it whatever the list says, and spending weeks on documentation can become a polite way of not deciding. I have watched a company use “we’re still assessing” as a reason to do nothing for a year while their best supervisor quietly burned out.
So I concede both. Time-box the list hard, two weeks and no more, and treat it as an inventory, never a specification. Its job is to make sure you drop things on purpose rather than by accident. The fashion 3PL would have been perfectly happy to lose that nightly SKU merge if they had known it existed and fixed the catalogue feed upstream instead. What hurt them was finding out from a returns integration two weeks into a new system.
If I were starting on Monday, I’d book the receiving supervisor for Tuesday afternoon, open a blank document titled “Things the WMS does”, and refuse to let anyone say the name of a vendor until it ran to a hundred lines.
