Modernizing a 12-Year-Old Warehouse System Without Stopping the Trucks

The most dangerous software in a small business is the software that works. Not the buggy tool everyone complains about — that one gets replaced eventually. The dangerous one is the twelve-year-old system that nobody loves but everybody depends on, the one that boots from a beige tower in the corner and has been running the warehouse since before half the team was hired. It works. Until the day it almost doesn't, and everyone realises at once that the entire business is balanced on top of it.

This is the story of one of those systems, and how we replaced it. The client is a regional distributor — a few thousand product lines, a single warehouse, around thirty staff across the floor and the office. We've anonymised them and rounded the numbers, but the shape of the project is exactly as it happened. If you're sitting on an aging system you're afraid to touch, this is roughly what a sane modernisation looks like from the inside.

There's no heroic rewrite in this story, no weekend where we flipped a switch and everything was new. The whole point — the thing that made it work — is that nothing dramatic happened. The trucks kept loading. The warehouse barely noticed the floor shifting under it. That's the goal with legacy work, and it's worth understanding why.

The situation: a system held together by one person's memory

The warehouse ran on a custom system built around 2013 by a developer who had long since moved on. It did the core job — track stock, print picking lists, push orders out the door — and on a normal day it did it fine. The problem wasn't really the software. The problem was everything that had grown around the software to keep it usable.

Over a decade, the team had quietly built a shadow system out of duct tape: a spreadsheet for the stock counts the software got wrong, a second spreadsheet that reconciled the first one against reality, a WhatsApp group for the warehouse manager to flag items the system couldn't represent, and a printed binder of workarounds that new hires had to memorise. None of this was written down in one place. It lived in the head of the operations manager, a calm woman in her fifties who had been there fourteen years and was, functionally, the documentation.

When the owner first called us, it wasn't because of a crash. It was because she'd announced she wanted to retire in two years, and he'd done the maths and realised that the day she left, a meaningful chunk of how the warehouse actually functioned would walk out the door with her. That's a more common trigger for modernisation than any technical failure: not the system breaking, but the realisation that the people patching it won't be around forever.

The symptoms everyone had stopped noticing

When we spent our first two days just watching the warehouse work, the costs of the old system were everywhere — but they'd become so normal that nobody flagged them as problems anymore. Stock figures were trusted to be wrong by a predictable margin, so every big order got a manual physical check 'just in case.' New staff took weeks to become useful because so much of the job was unwritten lore. And the system ran on an operating system so old it could no longer be patched, sitting on a network the owner privately knew was a security incident waiting to happen.

• Inventory accuracy hovered around 80%, so staff double-checked counts by hand on anything important — hours a day, quietly.
• The picking-list logic couldn't handle the warehouse's current layout, so pickers walked a route the binder told them, not the screen.
• Month-end stock reconciliation took two people the better part of three days.
• Only one machine could run the admin side of the software, and if it died, nobody had a clear plan.
• Nothing connected to the online order channel the company had added in 2019 — those orders were re-typed by hand.

What we deliberately did not do

The obvious move — the one a lot of vendors would have pitched — is to buy a big warehouse management platform off the shelf, migrate everything over one weekend, and switch the old system off Monday morning. We've watched that approach go wrong enough times that we wouldn't propose it for a business like this. A big-bang cutover assumes you understand the old system completely. With a decade of undocumented workarounds, nobody did — not even the people running it.

The second tempting move is a full custom rewrite from scratch: take everything the old system does, rebuild it cleanly, ship the new one. That sounds responsible and it's a classic way to burn a year and a large budget while the business waits, frozen, for a replacement that keeps slipping. The trouble is that a rewrite has to reproduce every quirk before it can launch — including the quirks nobody remembers are load-bearing until they're missing.

So we didn't do either. We treated the old system not as a thing to demolish, but as a thing to surround and slowly replace — one capability at a time, with the old system still running underneath as a safety net the entire way. Unglamorous. Also the only version of this that reliably works.

The approach: strangle the old system, don't blow it up

There's a well-worn name for this pattern among developers — the 'strangler' approach, named after a vine that grows around a tree until it can stand on its own and the original quietly disappears. You don't replace the old system in one move. You build new pieces around it, route real work to them one at a time, and let the old system shrink until what's left is small enough to switch off without anyone holding their breath.

For this warehouse, that meant agreeing up front on a sequence: which capability we'd peel off first, which we'd save for last, and — crucially — a rule that at every stage, if the new piece misbehaved, we could fall straight back to the old way that same day. No step was allowed to be a point of no return until the very end. That single rule is what let the owner sleep, and what let the warehouse staff trust the project instead of bracing against it.

1. 1
   Map what the system actually does

   Three weeks of shadowing the floor and the office to document the real workflow — including every spreadsheet and binder workaround. We wrote down the system that existed, not the one the original spec described.
2. 2
   Fix the data before moving it

   We ran a full physical stock count and cleaned the product database against it. Migrating dirty data into a new system just gives you a faster wrong answer — so this came before any new software touched the data.
3. 3
   Replace the most painful piece first

   We built the new stock-tracking and counting module, ran it in parallel with the old one, and only trusted it once the numbers matched reality for a full month.
4. 4
   Connect the channels the old system ignored

   Next we wired the online order channel directly into the new stock data, killing the manual re-typing that had quietly existed since 2019.
5. 5
   Peel off the rest, then retire the old core

   Picking, reporting and reconciliation moved over one at a time. When almost nothing real ran on the old system, we finally switched it off — a non-event by then.

The parts that were genuinely hard

It would be dishonest to present this as smooth. The technical work was the easy part. The hard parts were human and procedural, and they're the same hard parts on almost every legacy project.

The undocumented rule that broke a feature

Two weeks into running the new stock module in parallel, the numbers drifted for one product category and we couldn't see why. After a day of digging, the operations manager mentioned, almost in passing, that certain bulk items were counted by pallet, not by unit, and the old system had a hidden conversion baked in that nobody had documented in a decade. It wasn't in any spec. It lived only in her head and the binder. We'd never have found it from the code alone — only from running both systems side by side and asking why they disagreed. That's the entire argument for parallel running in one anecdote.

Winning over the floor

The warehouse staff had survived more than one well-meaning 'improvement' that made their day worse, so they met the project with reasonable suspicion. We didn't fight it with a presentation. We picked the picker who complained loudest, sat with him for a morning, and rebuilt the picking screen around how he actually walked the floor. Once he started defending the new system in the break room, the rest followed. On legacy projects the toughest critic, won over, becomes your best advocate — and you cannot buy that with a memo.

The results, a year on

We're wary of glossy before-and-after numbers, because every business measures differently and yours will vary. So treat these as honest, rounded figures from one project, meant to show the shape of the return rather than a promise. The headline is less about any single metric and more about what stopped being scary.

The number the owner cared about most wasn't on any chart. It was that when the operations manager did retire — a few months ahead of schedule, as it turned out — the warehouse didn't even wobble. The knowledge that used to live in her head now lived in a system anyone could be trained on in days. The original reason for the whole project was quietly, completely solved.

If you're sitting on a system like this

Most owners with an aging core system feel the same two things at once: it's risky to keep, and it's terrifying to replace. Both are true. The mistake is letting the second fear win, because the risk of the old system doesn't hold steady — it grows quietly every year, as the people who understand it get closer to leaving and the platform it runs on drifts further out of support.

You don't have to pick between 'leave it alone and pray' and 'bet the company on a big rewrite.' The middle path — surround it, replace it a piece at a time, keep the old one as a net until the new one has earned trust — is slower and far less heroic. It's also the version that doesn't stop the trucks. If there's one thing to take from this whole story, that's it.

Common questions