Here's the verdict up front: a data freeze point is never just a timestamp IT picks on a slide. It is the point in time a warehouse can afford to stop doing business — and that price tag has to be calculated, not guessed. I've watched too many WMS projects where the freeze was penciled in as "Sunday 2:00 AM," only for the last wave of the night to still be running at 3 AM. The freeze slipped to daybreak, and the new system went live on day one with inventory numbers that didn't match anything.
In 2021 I helped a 3PL in Fontana cut over to a new WMS — 120,000 square feet, 18,000 outbound orders a day in peak season. We set the freeze for Saturday at 10 PM. Why that hour? We ran the numbers: Saturday volume there runs about 40% of a weekday. Stopping operations at 10 PM on a Saturday cost us at most 800 orders, and Sunday's schedule could absorb the catch-up. Sunday 2 AM looked better on paper, but the night shift's last wave lands around 11:30 PM — the building never truly goes quiet. The freeze has to sit inside a real valley in your business, not on a round number on the calendar.
What you're actually freezing: three lines, each by name
Most teams think "freeze" means "lock the old system so nobody can touch it." That's too crude. A freeze really locks down three states, and you need all three:
Receiving — the inbound line stops. Trucks are still on the road, appointment slots are still open — that inventory is in transit, not part of the frozen snapshot, but it must be logged. Stop creating new receiving appointments at least 4 hours before the freeze. Freight that already arrived goes to a staging area: unloaded, logged on paper, never entered into the system. Give your unload crew those hours — they need time to clear whatever is already on their docks.
Picking — waves go to zero. This is the dangerous one. Before the freeze, every live wave has to finish: picked orders ship out, unfinished waves get force-closed and handed back as "incomplete waves" in the old system. On one project, 37 waves were still live when someone forced the cutover. Every pick task from those waves vanished in the migration, and the warehouse spent two days matching orders by hand. Do the math with me: 8,000 SKUs, two days of chaos, carrier penalties and overtime — over $60,000 gone.
Shipping — the outbound door closes. After the freeze, no outbound move is allowed in the old system. Cartons already picked but not yet loaded either get loaded and shipped, or get returned to inventory and recorded as such. Nothing may sit in the "picked but not shipped" limbo — the migrated snapshot has no row for it, and it becomes ghost inventory.
Only when all three lines are defined is the freeze point real instead of decorative.
Working backward: every hour of downtime has a price
Here is how I build the timeline, working backward from a 10:00 PM Saturday freeze:
- 6:00 PM — stop inbound: no new receiving appointments; unloading goes to staging only
- 8:00 PM — stop picking: no new waves released; crews burn down the live ones
- 9:30 PM — wave cutoff: unfinished waves are force-closed, task paperwork recovered
- 10:00 PM — freeze: old system locked, inventory snapshot exported
- 10:00 PM–midnight — variance check: cycle-count high-value SKUs and known troublemakers
- Midnight–2:00 AM — import into the new system, verify row counts line up
- 2:00 AM — dry run: 3–5 small waves released in the new system, pickers walk it for real
- 6:00 AM — normal operations resume
Every hour the building sits idle costs money. That Fontana warehouse lost roughly $9,000 of throughput over four quiet Saturday hours. Now compare: the one botched data migration I personally lived through cost two days and over $60,000. Two extra hours of planned downtime buys you peace for the entire first week. Walk your boss through that arithmetic — in a WMS cutover, the most expensive line item is never the software license. It's rework after bad data.
And one rule I learned the hard way: never cut over on a Monday. Monday mornings stack the weekend's backlog on top of fresh orders — one of the busiest windows of the week. I watched a client insist on a Monday 12:00 AM cutover because "the week starts with clean data." Sunday night's catch-up shift ran long, the freeze slipped to 4 AM, the import job never finished, and 60 pickers stood idle at 8 AM with nothing to do. My rule since then: put the freeze in the back half of a real business valley. Stop two hours early rather than cut over under a peak.
Cutting over the inventory: three ledgers, not one
When the freeze hits, you export one snapshot: every SKU in every location. But real warehouse inventory is never that tidy. You need two more ledgers alongside it:
The variance ledger. After the snapshot exports, cycle-count a sample — I usually take 10–15% of SKU rows, weighted toward high-value items and SKUs with a history of variance. Investigate on the spot anything off by more than 2%. Import the rest as-is from the old system but flag them "pending review" and watch them closely in week one. Do not chase 100% reconciliation at 1 AM — you don't have the time, and the crew is exhausted. Being off on 2% of SKUs costs far less than half a day of downtime.
The in-transit ledger. Staging pallets, picked-not-shipped cartons, a loaded trailer that never left — the snapshot shows none of these, or only half. Make a paper ticket for every in-transit batch: SKU, quantity, status (awaiting putaway / awaiting ship / on trailer), and re-enter them in the new system the next day. The worst case I ever saw: 12 pallets sat in staging for three days because neither system had a record of them. Nobody knew until a customer called about a missing shipment.
The unfinished-wave ledger. Two options for waves that didn't finish: (A) migrate the wave tasks into the new system as-is — this needs the old and new task formats to match, tested in advance; or (B) kill the waves, return the tasks to unassigned status, and re-release them in the new system. I almost always pick B. Format mismatches are a bigger risk than re-releasing, which costs at most an hour.
The checklist version
Something you can use tomorrow. Print this and pin it to the warehouse office wall one week before cutover:
- Freeze time: ______ (in the back half of a business valley — no superstition about round hours)
- Inbound stops ____ hours ahead (suggest 4+); picking stops ____ hours ahead (suggest 2+)
- Wave cutoff time: ______; unfinished-wave plan: A migrate / B kill-and-re-release (suggest B)
- Snapshot export owner: ______; cycle-count scope: ______ SKU rows
- Paper tickets for in-transit freight printed: yes / no
- Dry run: 3–5 small waves, walked by real pickers, passed: yes / no
- Rollback trigger: if the import fails, by what time do we call it and roll back to the old system? ______ (decide this in advance — nobody thinks clearly at 3 AM)
And a real question to take home: how much ghost inventory does your warehouse have right now — picked but not shipped, received but not put away, orders created with freight untouched? If you can't answer that number today, the prettiest freeze timeline in the world won't save you. Clean up the black inventory first, then talk about cutover.
