A warehouse cutover is unusual among go-lives because the operation cannot pause. Finance can close a period late. A dock cannot hold a truck for three hours while someone works out why a pick list will not print.
That single constraint drives everything below. The question is never "will it work" — it is "when it does not work at 06:40 on a Monday, what do the people on the floor do".
Before the window: the decision that makes rollback possible
There is exactly one decision that determines whether you can roll back, and it has to be made weeks ahead: the old system stays authoritative until a named person says otherwise, and everything the new system does in the interim is reversible.
In practice that means no destructive migration. You do not switch off the old system, you make it read-only. You do not overwrite balances, you load them. If a rollback happens, the old system is still the truth and the new one is discarded. Teams that skip this end up unable to go back and unable to go forward, which is the worst place a cutover can land.
Two weeks out
Freeze the master data. No new item codes, locations or customers in the old system. Every late addition is a row that has to be migrated twice and reconciled twice.
Name the rollback authority. One person, with a deputy, who can call it. If three people have to agree, nobody calls it and you limp forward on a broken system.
Agree the abort criteria in writing. Not a feeling. Something measurable: picks not confirming after thirty minutes, or the stock ledger disagreeing with two consecutive counts.
Run the load end to end on production hardware. A load that works on a laptop and fails on the real database at real volume is a common and entirely avoidable surprise.
Print the paper fallback. Pick lists, dispatch notes and labels for the first day, printed and physically in the building. If the system is down, work continues on paper and is keyed later.
The last shift on the old system
Stop putaway before you stop picking. Inbound can wait in a staging area with a paper record. Outbound has a truck attached to it. Sequence the freeze accordingly.
Clear or document work in progress. Every half-picked order and every pallet in transit between locations either completes or gets written down as a known exception before the count.
Count what you are about to trust. Full count if you can afford the window, a targeted count of high-value and fast-moving locations if you cannot. The count is your opening balance and everything downstream inherits its errors.
Make the old system read-only, not off. Access for lookup, no ability to post. It is your reference for the first cycle and your fallback if you roll back.
Load, then reconcile, then stop. Load the opening position and reconcile it against the count before anyone touches the new system. If the reconciliation fails, this is the cheapest moment to abort.
The reconciliation after the load is the real go or no-go. Everything before it is preparation and everything after it is expensive to undo.
Implementation lead, AxonRaysFirst shift on the new system
Stand on the floor. Not in a war room. Next to the people scanning, watching what they hesitate over. The first day tells you more about your configuration than any test cycle.
Release work in small waves. Half the normal wave size for the first day. Slower throughput is a cost you have budgeted for. A queue of confused pickers is not.
Log every workaround. Anything anyone does outside the designed process gets written down, even the harmless-looking ones. Undocumented workarounds become permanent within a fortnight.
Count again at the end of the shift. A targeted count on locations touched that day. It is the fastest way to find a configuration error while it has only affected one shift.
Keep the paper fallback in the building. For at least a week. It costs nothing to leave it there and it is the difference between a slow day and a stopped dock.
The first month
Two things matter after stabilisation, and both are easy to skip once the panic has passed. Work the exception queue down to zero at least once, so you know what steady state actually looks like. And close the first full period on the new system with finance in the room, because a warehouse that runs beautifully but does not reconcile to the ledger is not finished.
What this checklist assumes
That you are cutting over one site at a time. Multi-site big-bang cutovers are occasionally unavoidable and always more expensive, because you lose the ability to learn from the first building before touching the second. If you have the option to phase it, phase it. The first site pays for the lesson and the rest inherit it.