Parallel Run: Reconciling Old and New WMS Data During a One-Month Cutover

Bottom line up front: during a WMS cutover, run the old and new systems in parallel for at least two weeks, ideally four. Set the inventory variance tolerance at 0.5% — hard line — and zero tolerance for order status mismatches. Reconcile the same three reports every day. If anything breaches tolerance, freeze transactions in the new system and trace back to the old one. That one rule will save your go-live.

What a parallel run is actually reconciling

A parallel run means both systems stay live: the legacy WMS keeps running real operations while the new WMS records the same transactions in parallel. It sounds like double the work. It is double the work. And it is the only way to sleep at night during cutover.

Two reasons.

First, no matter how clean your migrated data looks, day one will collide with reality. Legacy systems are full of "invisible inventory": pallets staged in the aisle, returns tracked in someone's spreadsheet, orders that shipped but were never closed. The new system inherits the book numbers; the book numbers and the physical floor diverge fast. I have seen this exact failure three times. In April 2024, an auto parts warehouse in Dallas, Texas ran a parallel period of only 7 days and cut the old system loose. Month-end count came up short by roughly $110,000 in inventory. The root cause: lot-level variance was never in the reconciliation scope. The old system tracked lots loosely; the new system enforced them strictly. They reconciled for a week and compared the wrong things.

Second, operators need time to retrain their hands. Picking throughput typically drops 20–30% in the first week after a system change. That is not a people problem; it is muscle memory. The parallel period is the buffer: if the new system entry is wrong, the old system still covers production.

So the parallel run is not reconciling "data." It is reconciling three specific reports:

1. Inventory reconciliation: on-hand quantity by SKU × location, compared line by line.
2. Order status reconciliation: open, allocated, shipped, cancelled — compared order by order.
3. Location occupancy reconciliation: which locations are occupied and with what, compared slot by slot.

Only these three. Reconcile more and you will never finish. Never finishing is the same as never reconciling.

The daily reconciliation in five steps

Step 1: Freeze a baseline. Before the parallel period starts, do a full physical count, or cycle-count your way to 95%+ SKU coverage. Without a clean starting point, every variance afterward is unexplainable. This is the step management loves to skip — "let's just start, don't waste time." Do not listen. Reconciliation without a baseline is theater.

Step 2: Lock the reconciliation scope in writing. Three things must match exactly: the same snapshot time every day (say, midnight — and ask when the legacy system's nightly batch jobs run first), the same dimensions (SKU + location + lot, all three — Dallas is what happens when you skip one), and the same unit of measure (eaches vs. cases; mixed UOMs in legacy systems are the norm, not the exception).

Step 3: Run the three reports at the same fixed time every day, before the morning shift starts, covering the prior day's closed business. Results come out the same day, no exceptions. A variance that sits overnight becomes unexplainable by morning.

Step 4: Triage variances into three tiers. This is the most important table in the whole method. Print it and tape it to the wall:

Note what the fatal-tier action freezes: the new system, not the old one. During parallel run, the legacy system is the production system. The new system is the shadow. When the shadow is wrong, the shadow stops.

Step 5: A 15-minute standup every day. Three questions only: how many fatal variances today, what caused them, who owns each one. Skip the standup and the reconciliation reports become an Excel file nobody reads.

Now the math, because management always asks whether the parallel run is worth it. Take a 15-person operation: two extra hours of double entry per person per day, at $25/hour, for 30 days — that's 15 × 2 × 30 × 25 = $22,500. Now price one failed cutover: the Dallas warehouse's $110,000 inventory write-off was only the book loss. The real bill was two months of overtime counts, customer claims, and emergency line stops, plus a floor team that stopped trusting the system. $22,500 versus that. Not the same league. This is arithmetic a CFO understands.

How long to run, and when to kill the old system

The answer first: two weeks minimum, four weeks ideal, past six weeks you are burning money.

Here is the counterintuitive part: longer is not better. Past six weeks, operators start "riding two horses" — entering into both systems, carefully into neither — and data quality decays instead of improving. I watched one warehouse parallel-run for three months. Both systems ended up full of garbage. Three months of work for nothing.

The kill signals for the legacy system — all three required, no exceptions:

1. Seven consecutive days with all three reconciliation reports inside tolerance (inventory within 0.5%, order status at zero variance).
2. Zero fatal variances for seven consecutive days. Zero, not "within tolerance."
3. Operators have run a full week independently on the new system, with the legacy system kept only as backup — shadow mode, proven smooth.

One more counterintuitive tell: a reconciliation that shows zero variance for days is suspicious, not reassuring. A real warehouse always has in-transit stock and timing gaps. Days of flat zero usually mean someone is hand-smoothing the report. If you see three straight days of zero, audit the person doing the reconciliation before you celebrate.

The usual failure modes, and the go-live-eve checklist

Ranked by how often I have seen them:

First, legacy scheduled jobs left running. November 2023, a 120,000-square-foot apparel 3PL in Ontario, California, 18,000 SKUs, nine years on the legacy system. Go-live eve, 2 a.m.: the variance report that showed 200-odd lines during the day suddenly exploded to 1,400. The whole team stayed up until dawn and found it: a legacy batch job at 1 a.m. that re-posted "reserved inventory" — a logic the new system did not have. The two systems fought each other all night. I have seen this exact failure three times, always in the small hours, always a scheduled job. Before the parallel period starts, list every legacy scheduled job and confirm each one.

Second, the two sides define the same word differently. Does "on-hand" include the QA hold area? The staging lane? Settle this in Step 2, in writing, signed by both sides.

Third, variances with no owner. The report runs, the fatal variance sits there for three days, nobody acts — that is the same as no reconciliation. The Step 5 standup exists for exactly this.

Fourth, killing the legacy system too early. Management sees a smooth parallel run and wants to save the $22,500 in labor. Hold the line on the three kill signals. All three, or no cut.

Finally, the go-live-eve checklist. Every item gets a check mark, or the cut does not happen:

1. Today's three reconciliation reports are all within tolerance, with zero fatal variances.
2. Every legacy scheduled job is disabled — confirmed item by item against the list.
3. Rollback is ready: full legacy database backup completed, cutover switch tested live.
4. Key users (receiving, picking, and shipping leads) have operated independently on the new system for a full week.
5. The implementation consultant's and IT's phones stay on until noon the next day. Laugh if you want — I know a site where someone powered off on go-live night.

A parallel run is not a technical problem. It is a discipline problem. Scope, tolerance, standup, checklist — get those four right and the odds of a cutover disaster drop to near zero. Skip them, and do not cut over at all.

By Lin Xiao, WMS Implementation Consultant