Running Two WMS in Parallel: Three Root Causes of Data Mismatch

Here's the conclusion up front: when you switch WMS and run the old and new systems side by side, the numbers will not match. Almost never. And the gap is rarely "someone miscalculated." It comes down to three root causes — out-of-sync master data, process timing differences, and double-entry misses or dropped interface orders. A one-to-three-month parallel run cannot eliminate the differences. What it can do is lock them in a cage: reconcile at fixed times with fixed definitions, and close every variance the same day. Do that, and you'll sleep the night you cut over.

I've seen this trap three times. The worst was a 2022 auto-parts distributor — the old system had run for nearly a decade, and the new cloud WMS went live. The owner decided on a three-month parallel run: "we cut over when it's stable." By week two, the two systems disagreed on more than twenty SKUs, and nobody could reconcile them. IT spent a day in the interface logs. Nothing. The answer came from the floor: in the old system the SKU was "A-1234"; the import script scrubbed the hyphen, so the new system held "A1234." Two codes, two records — one over and one under on every report. All twenty-plus SKUs looked exactly like that. One hyphen. Two days of overtime.

That story hides the most punishing truth about a parallel run: nine times out of ten, the mismatch is not a system bug. The two systems simply never stood on the same starting line.

Root Cause 1: Master Data Out of Sync During the Parallel Run

The first step of parallel-run reconciliation is not checking transactions. It's checking master data. SKU codes and bin codes in the old and new WMS have to be matched line by line. The usual failure points — I flag this red on every go-live eve checklist:

1. Inconsistent code-cleaning rules. The old system tolerated mixed case, full-width characters, and stray symbols; the new one standardized everything (hyphens stripped, uppercase, half-width). Same SKU, different codes on each side.
2. The bin scheme got redesigned. The new WMS introduced a new bin coding scheme before the old bins were fully mapped, so bin-level variances were unreconcilable from day one.
3. Different availability definitions. The old system counted in-QC stock as "available"; the new one excluded it. With the definitions mismatched, the reports were born apart.

The fix: before the parallel run starts, build a master data crosswalk — one sheet for SKUs, one for bins, old and new codes side by side, every variance highlighted. Nothing moves to transaction reconciliation until that sheet is clean. I make the warehouse lead and IT both sign it. After that signature, this class of variance should be extinct.

Root Cause 2: Process Timing Differences — the "In-Transit" Stock Between Two Snapshots

This is the most unfair variance. In 2023, a consumer-goods client came to me in week three of their parallel run: the new system showed several thousand cases less than the old one. "Is someone stealing?" An afternoon of digging found the goods sitting in the QC room. The old flow was receive-and-putaway — stock available the moment the truck arrived. The new flow was receive, then QC, then putaway. The missing cases were two truckloads that arrived that day: counted by the old system, still sitting in QC in the new one. Neither system was wrong. The mistake was checking inventory "at the same moment" as if the moments meant the same thing.

A parallel run must define "same time, same definition." My approach:

1. Reconcile at three fixed times daily: before the morning shift, at midday handover, and after the night shift.
2. Reconcile on the total — available plus in-transit plus in-QC — not on a single status. Drill into statuses only when the total disagrees.
3. Give in-transit and in-QC their own lines on the report. During a parallel run, those two lines exist to house timing differences. Write the cause down, and chase closure the next day.

One line to remember: you reconcile definitions, not numbers. Get the definitions aligned and every variance has an explanation.

Root Cause 3: Double Entry and Dropped Interface Orders — When the New System Becomes a Photo Op

The most common parallel-run pattern: the operator walks the process in the new system, then re-enters it in the old one. I've seen this setup three times; it broke every time. The moment the floor gets busy, double entry deforms: the new system has the shipment, the old one never got the receipt posted; the old one has the return, the new one never got the return order. More insidious are dropped interface orders: the interface only transmitted whole orders. A supplier split a delivery across two trucks; truck one went into the new system, truck two only into the old one. The interface log was spotless — because the interface never saw truck two.

The signature of this class: random, one-off, small amounts — but they accumulate. The treatment:

1. Double entry needs a fixed order. Which system first, which second, written into the SOP — first-new-then-old, say. Reverse the order and it counts as a violation.
2. End-of-day double-entry closure: every inbound, outbound, and return order created in the new system that day must be found in the old one. Anything missing gets re-entered the same day. Nothing carries overnight.
3. Interface probes: a scheduled daily job compares order counts between the two systems (inbounds, outbounds, adjustments). When counts disagree, check the interface first, then the humans.
4. Weekly spot counts: pick a few dozen SKUs at random and reconcile physical stock, old system, and new system — three-way. Deformed double entry and dropped orders all show up.

The Counterintuitive Call: a Longer Parallel Run Is Not a Safer One

Plenty of owners think three months of parallel run isn't enough and six would be safer. I disagree. The longer the parallel run, the worse three things get. First, the people doing double entry relax — "the old system is still running anyway" is a natural excuse, and new-system data quality decays month by month. Second, variances pile up and the reconciliation team goes from "zero it daily" to "we'll deal with it before cutover." Third, the business gets used to two systems, the urgency to cut over evaporates, and the hard cut keeps sliding.

My experience: one to three months is the sweet spot. Under a month, problems don't surface. Past three months, diminishing returns — morale goes first. The value of a parallel run is not "run it long." It's "reconcile it for real, every day."

Picking the Cutover Moment: Three Hard Conditions for Ending the WMS Parallel Run

On cutover night, every owner fears the same thing: "what if the inventory is wrong after we switch?" Don't pick the date by gut. Set three hard conditions and cut over only when all three hold:

Miss one condition, push cutover a week — but cap it at two pushes. Still failing after two pushes means the problem isn't the date, it's parallel-run discipline. Go back and audit the reconciliation.

And one piece of blunt advice: cut over in a business lull. Never the week before peak season or a promo. On cutover night, the warehouse stands down for half a day — opening count, old-system lockout. That half day of downtime costs far less than a botched cutover.

Go-Live Eve Checklist (for Closing Out the Parallel Run)

1. Master data crosswalk: every SKU and bin matched old-to-new, variances zeroed, warehouse + IT signed.
2. Reconciliation definitions on paper: the three daily times, how in-transit and in-QC are counted. In writing.
3. Double-entry order SOP: new-first-then-old (or the reverse), everyone trained and signed.
4. Interface probes: daily automatic count comparison, with someone actually watching the alerts.
5. Spot-count records: weekly, three-way, filed.
6. Cutover conditions: 7-day evidence packs complete.
7. Cutover-night roster: who counts, who locks the old system, who's on call — names on the wall.

I've seen this trap three times, and it was never the technology that failed. It was discipline. Get that discipline in place and cutover is a formality; lose it and six months of parallel run is just digging your own hole.

By Lin Xiao, WMS Implementation Consultant