slug: wms-data-migration-cutover-playbook-guide lang: en title: Switching WMS: Data Migration Checklist and Cutover-Night Playbook excerpt: Data migration is where WMS switches go to die. Susan breaks it down from the vendor side: what free migration really covers, the master-data cleanup checklist, and cutover-night planning. section: software subcategory: wms region: common tags: ['wms','data-migration','cutover','master-data','go-live'] author: 苏珊
Switching WMS: Data Migration Checklist and Cutover-Night Playbook
We had a client — a beauty-products 3PL doing 8,000 orders a day — that decided to switch its WMS last spring. The salesperson was a friend of mine. Cutover was scheduled for Sunday midnight, with the warehouse reopening Monday at 6 a.m. He told me, "The contract includes free data migration, what could go wrong?" Monday morning they mis-shipped over 400 orders. The same product lived under three different item codes in master data, old and new location codes were mixed together, and lot and expiry formats were a mess. That week cost them nearly $20,000 in claims, plus one major client walked away. So here's my advice to every buyer reading this: the biggest cost of switching systems is never the software license. It's data migration. You can negotiate the license down to nothing, but if the data isn't clean, cutover night will take it all back.
What "free data migration" in the contract actually covers
Let me put the ugly truth first. I've read hundreds of these contracts. That line about "free data migration" usually covers only this: standard template imports (basic SKU info, locations, vendors, customers), plus one or two rounds of import support. What it typically does not cover is where the pain lives:
- Historical inventory snapshots: does the old system's live inventory come over? As of what exact timestamp?
- Lots and expiry dates: the lifeblood of food, beauty, and pharma clients — many "free" packages don't include lot records at all
- Open documents: inbound receipts in transit, unfinished waves, unshipped orders — whose problem are they on cutover night?
- Serial number records: lose these on high-value goods and the customer complaints write themselves
- Billing rules and rate cards: a 3PL that loses its billing logic can't invoice correctly from day one
Negotiation advice: put all five items into a contract appendix, marked "included" or "excluded" — and priced if excluded. A verbal "we cover everything" counts for nothing at 3 a.m. on cutover night. I've watched too many salespeople promise the moon to close a deal, only for the implementation team to show up and say "we don't do that." Don't ask me how I know — we've done it ourselves.
The master data cleansing checklist for WMS data migration
Eighty percent of data migration work isn't "migration" — it's cleansing. Data that has lived in an old system for years is dirty by default. This is the checklist I tell every switching client to finish four weeks before cutover:
1. One product, multiple codes. The same physical item under two or three codes is the most common dirty data there is. Causes vary: a vendor change, a promo that spawned a temporary code, an operator who created one on the fly. The standard: one master code per physical item, a mapping table for the rest, legacy codes retired within 30 days after cutover.
2. Duplicate barcodes. Different SKUs sharing one barcode — the scanner reads the barcode correctly and the system ties it to the wrong product. Most of that beauty 3PL's 400 mis-shipped orders came from this. Cleansing method: export the full barcode-to-SKU mapping and script the duplicate check. Don't eyeball it; no human survives tens of thousands of rows.
3. Location coding rules. Old locations may have been "made up a decade ago"; the new WMS demands a strict zone-aisle-bay-level-position scheme. Freeze an old-to-new location cross-reference before cutover and tape it to the wall. Don't count on operators "remembering" — nobody remembers anything at 3 a.m.
4. Lot and expiry formats. The old system uses MM/DD/YYYY, the new one wants YYYY-MM-DD, or the reverse. Mismatched formats and expiry management collapses on day one. For food and pharma clients, this one is a red line.
5. Units of measure and conversions. Case-to-each conversion: 24 per case or 12 per case? The old system may hold both for the same SKU. Verify SKU by SKU. No shortcuts.
6. Vendor and customer master data. Duplicate vendor names, dead customer codes from accounts long closed — archive them before cutover. Keeping them is planting mines in the new system.
A counterintuitive judgment call: don't chase 100% clean data — chase 100% clean critical fields. SKU codes, barcodes, locations, lot/expiry, conversion factors: these five must be perfect. Vendor phone numbers and the like can be fixed after cutover. Time is always short, so spend your ammunition where it matters.
The cutover window: weekend shutdown or parallel run
Every client faces this trade-off. There is no standard answer, only arithmetic.
Option A: Weekend shutdown cutover. Freeze order intake Friday 8 p.m. — the old system ships but doesn't receive. Saturday: migrate data, run validation. Sunday early hours: trial runs, warehouse reopens Monday morning. Clean: one dataset, one source of truth. The catch: the window is fixed — overrun it and Monday morning is a meltdown with customer service phones ringing off the hook. Fits mid-volume warehouses with relatively simple operations.
Option B: Parallel run. Old and new systems run side by side for one to two weeks, old system live, new system shadowing, reconciled daily. Safe: cutover risk is spread thin. The catch: labor literally doubles, operators key everything twice, and reconciliation will make you question your life choices. Fits large warehouses pushing 10,000-plus orders a day that cannot afford to stop.
Do the math: at 8,000 orders a day, a 12-hour shutdown backlogs roughly 4,000 orders (assuming even distribution across 24 hours — adjust for your wave schedule), needing about 1.5x staffing on Monday to clear, plus overtime and complaint costs. A two-week parallel run means paying two weeks of extra operations labor — roughly half a month of labor cost. Which is more expensive depends on your volume and labor cost structure. Let finance run the numbers, not IT gut feel.
Our beauty client chose Option A, betting on a 36-hour weekend window. Data cleansing wasn't finished. At 2 a.m. Saturday they discovered lot and expiry records wouldn't import, the whole plan slipped six hours, and by Monday's reopening 15% of SKUs were still unvalidated — those 400 mis-shipped orders came almost entirely from that 15%.
The rollback plan: decide how you'll lose before you play
Most clients don't want to hear this section, but I'm in sales, so I'll say it: on cutover night, the most dangerous thing isn't the technology — it's people. At 3 a.m., nobody makes good technical decisions. So every decision gets written down in daylight; at night you only execute.
A rollback plan needs at least three things in writing:
- The freeze point. Before cutover begins, snapshot the old system's full dataset, timestamped to the minute. This is your last regret pill.
- The rollback trigger. For example: "data validation not passed by 4 a.m." or "more than two core-process trial runs failed" — trigger the rollback, no debate, no hesitation. The trigger line goes into the cutover plan, signed by everyone.
- The old-system retention period. Keep the old system readable for at least 30 days after cutover. Don't rush to shut it down — historical orders and lot lookups will need it.
Next time you negotiate a contract, ask these three questions
One: which tables does "free data migration" actually cover? Historical inventory, lot and expiry, open documents, serial numbers, billing rules — confirm each one, in the appendix.
Two: what are the responsibilities and rollback triggers if cutover overruns? If the implementer blows the timeline, what do they owe you — in writing.
Three: how long is old-system data retained, and in what export format? Don't discover the old system is gone the day you need a historical order for a dispute.
And one parting tease: when a salesperson tells you "we've migrated hundreds of clients with zero failures," reply, "Wonderful — then you won't mind spelling out the rollback terms in detail, since we'll never need them." The ones who dare to write it down are the confident ones. The ones who won't, know exactly why.
By Susan, 3PL Sales Director
