The most dangerous moment in a WMS replacement isn't go-live morning. It's the quiet stretch of hours right before it — the data freeze window — when the old system is winding down and the new one isn't trusted yet. Get the freeze point wrong and you'll spend your first week reconciling inventory instead of shipping orders.
I've watched teams spend six months on software selection and four months on implementation, then leave the freeze decision to the week before cutover. The result is always the same: a few hundred open waves still sitting in the old system on go-live day, inventory that doesn't tie out in the new one, and a customer service queue on fire. I saw it happen up close on a 3PL project in Fontana back in 2019. Once was enough.
The Freeze Is Three Lists, Not One Line
Most people picture the freeze as a single moment: old system stops, new system starts. In practice, the freeze point is three lists, each frozen on its own schedule.
The first list is master data, and it freezes earliest. Item masters, location masters, customer and vendor masters should be locked two to three weeks before cutover. The logic is simple: data migration and validation run against a snapshot, and if masters keep changing, your migration scripts are stale the moment they finish. My rule is that after the master freeze, additions go through an exception process only — a paper form, my signature, then into the system.
The second list is transactional balances, frozen the night before. The inventory balance snapshot, open sales orders, open purchase orders and receipts, pending inventory adjustments, unfinished cycle count tasks — all of it gets "photographed" before the cutover window opens. After the photo is taken, those documents in the old system may be closed but never created.
The third list is in-flight work, and it's the messy one. Waves that are picked but not verified, orders loaded on a trailer but not yet shipped, receipts sitting on a truck that hasn't been unloaded — these straddle both systems and each one needs an owner and a decision. My hard rule: close what can be closed. Only the exceptions carry into the new system, and every single one gets signed off by a named owner on the cutover checklist.
Size the Window From Your Order Volume, Not the Calendar
There is no standard freeze duration, but there is a way to calculate it. Work backward from your daily order volume, your wave rhythm, and how fast your team closes documents.
Start by picking the cutover window, then derive the freeze actions from it. For an e-commerce building doing a few thousand orders a day, I usually ask for one full low-volume window — say, Saturday 10 PM to Sunday 6 AM. Four to six hours before the window opens, stop creating new waves and let in-flight waves finish naturally. Two hours out, receiving goes to manual logs. When the window opens, take the inventory snapshot and lock write access on the old system.
One non-negotiable: run a count before the freeze. Not a full wall-to-wall — but cycle-count every high-velocity location the cutover touches. I've seen a project discover a three-point gap between system and physical inventory after the snapshot was taken, and the whole cutover slipped a week. The count is a precondition of the freeze, not an optional extra.
And one thing teams forget: tell your customers and carriers about the freeze window in advance. For a 3PL especially — if a client drops an urgent order during the freeze, you need a standard script explaining why those hours are dark. Don't write it when the phone rings.
Run Parallel Briefly — the Old System Is a Mirror, Not a Partner
Whether to run the two systems in parallel after cutover is a perennial argument. My position is blunt: yes, parallel — but the old system stays as a read-only rearview mirror, never as a second data entry point.
The mirror means the old system keeps query access for two to four weeks. Customer service looks up order history there, finance reconciles there, pre-cutover returns get processed there. But every new transaction goes into the new system. Entering new orders in both systems is the worst practice I've seen — the two datasets diverge within three days, and reconciliation becomes a nightmare.
I cap the parallel period at two weeks, a month at most. If you still can't live without the old system after a month, something in the new system wasn't finished, and the answer is to fix it — not to extend parallel running indefinitely. When the period ends, the old system gets archived: database backed up and sealed.
Write the Rollback Plan on Paper — Then Rehearse It
Finally, the rollback. Plenty of projects have a rollback plan that reads, in full: "If problems occur, revert to the old system." That is the same as having no plan.
A usable rollback plan spells out four things: the triggers (for example, core outbound flow down for more than two hours, or a major client's orders completely unfulfillable); the single decision-maker (one person, usually the project lead — not a committee); what happens to data created in the new system during the rollback (picked orders, printed labels — voided or manually written back); and when the rollback drill happens (my requirement: at least one full rehearsal before cutover, including a timed restore).
Here's the honest truth about rollback plans: their real value isn't in being used. It's in forcing you to think through every "what if" before cutover day. Every project I've run with a serious, written rollback plan never actually rolled back. Two of the ones without one called me at midnight.
If you're building a cutover plan this week, do one thing tonight: pull your open order list, lay it against your wave schedule, and count exactly how many orders will be in the air in the twelve hours on either side of your planned freeze point. That number is the foundation of your entire cutover plan. Build on sand and everything above it is a hazard.
