# WMS Cutover Checklist: Protect Inventory and Open Work at Go-Live

> A practical warehouse cutover run sheet for reconciling inventory, unfinished work, system ownership, and first-shift decisions when a WMS changes.

**Source:** https://sizelabs.com/blog/wms-cutover-checklist  
**Published:** 2026-10-09  
**Author:** Sizelabs  
**Topics:** WMS cutover, warehouse go-live, inventory migration, warehouse operations, implementation  
**Publisher:** Sizelabs Corp — AI-powered warehouse receiving automation.

---

A warehouse management system cutover is more than a software switch. At the transition, physical inventory, open warehouse work, and transactions can all be in different states. A **WMS cutover checklist** helps the project team agree on what finishes in the legacy system, what moves to the new one, and what must stop for review.

This guide is for operations and implementation teams changing the warehouse system of record. It covers cutover-day controls and the first shift. It is separate from a WMS selection template and from a dimensioning-system installation plan. Use the vendor's current migration procedure and the site's approved operating rules for system-specific steps; this general worksheet does not approve a production deployment.

## 1. Mark the cutover boundary before the final shift

Write down the exact time when the warehouse stops creating or completing work in the legacy WMS, when the new WMS becomes authoritative, and how inbound and outbound work will be handled during any transition window. Name the source of truth for each transaction type across that boundary. Do not leave a process relying on two systems to accept writes unless the implementation team has tested and approved that design.

Assign a primary owner and backup for inventory, open warehouse tasks, orders and shipments, item and location data, integrations and labels, user access, site operations, and support. Also identify who can call go or no-go, who can approve a controlled workaround, and who can authorize rollback. These roles should be known before the final data load, not decided while orders are waiting.

The project team should define its own entry criteria, tolerances, and stop conditions. There is no universal number of acceptable differences for every warehouse or WMS.

## 2. Give every unfinished transaction a disposition

Before the freeze, produce an exception list of work that has started but is not in a final state. Depending on the site's workflows, review:

- receipts, unloads, putaway, replenishment, and internal moves;
- picks, packing, staging, loading, and shipments awaiting confirmation;
- transfers, cycle counts, quality holds, returns, and work orders;
- labels, handling-unit or license-plate references, and integration messages awaiting a response.

For every item, record the approved disposition: finish it in the legacy system, carry it into the new WMS, cancel and recreate it, or hold it for a named owner to reconcile. The correct option depends on the WMS migration path and business rules. Prevent the same physical movement or shipment from being posted twice, and do not assume that an open task can be copied safely just because its screen fields look familiar.

SAP's EWM migration documentation, for example, calls out that certain stock tied to open inbound or outbound work may need to be processed, moved, or otherwise resolved before a particular migration. Those details are product- and migration-specific, so confirm the procedure for the actual source and target versions.

## 3. Reconcile the inventory snapshot and the target state

Agree on one timestamp for the source snapshot and define which inventory attributes must match in the target. These may include item, location, quantity, unit of measure, stock status, owner, lot or serial, and handling-unit identifier. Include the fields only when the warehouse uses them and the migration design carries them.

Compare more than a grand total. Review agreed totals and a sample of records by location, status, and workflow; check known exceptions such as held stock, active picks, partial receipts, and inventory in transit. Keep an owner and resolution record for every difference inside or outside the project's approved tolerance. A file that loaded successfully is not evidence that the warehouse can find and transact the stock correctly.

Confirm related data and controls needed for the first shift: item and location references, barcode rules, user roles, printers and scanners, shipping or carrier connections, and the integration queues that post warehouse events to other systems. Validate the flows the site will actually run first, such as receiving to putaway or pick to shipment confirmation.

## 4. Rehearse the run sheet, including the stop path

Run a mock cutover or dress rehearsal using the same sequence, roles, data extracts, communication, and verification steps planned for production. Time the work, capture where teams wait, and revise the instructions. Include the open-transaction cases that created uncertainty in the disposition list; a clean sample alone will not expose every handoff.

Practice both the expected path and the decision path if an agreed check fails. Specify who pauses new work, which system remains authoritative, how already-completed transactions are protected, and who decides whether to resume, use an approved contingency, or roll back. Keep recovery and reconciliation instructions in the plan rather than improvising a second source of truth.

Microsoft's implementation guidance recommends practicing the cutover plan, defining owners and go/no-go criteria, and confirming migrated data in production. Manhattan's published WMS implementation overview also describes mock conversion and risk assessment during preparation. Use these as planning references, then validate the actual steps with the selected WMS provider and project owners.

## 5. Use a record that makes each checkpoint visible

Copy this table into the approved project workspace. Use role names and internal record references; do not place customer, employee, or credential data in a broadly shared cutover sheet.

| Checkpoint | Evidence to attach or reference | Owner role | Decision |
| --- | --- | --- | --- |
| Legacy transaction boundary confirmed | Approved timestamp and communication record | Operations lead | Ready / hold |
| Open work assigned a disposition | Reconciled exception list and accountable owners | Workstream leads | Ready / hold |
| Inventory snapshot compared | Source and target totals, sample checks, difference owners | Inventory lead | Ready / hold |
| Interfaces and workstations verified | Test records for the first-shift workflows | IT and site leads | Ready / hold |
| Go/no-go decision recorded | Agreed criteria, unresolved issues, authorized decision | Decision owner | Go / no-go |
| First-shift review completed | Exceptions, follow-up, and support handoff | Shift lead | Continue / contain |

Set pass criteria before the rehearsal. At go/no-go, evaluate the agreed criteria together; a single green technology check should not override a material inventory or operating-process gap.

## 6. Reconcile the first shift before calling the cutover stable

During the first shift, review inventory differences, incomplete receipts and picks, held work, rejected or delayed messages, label and scan failures, access problems, and any manual fallback records. Assign each issue an owner, next action, and due checkpoint. Avoid replaying queued or duplicate transactions until the integration owner confirms how the target handles retries.

At shift close, reconcile the agreed source and target records for the work completed during the cutover, hand open issues to the support owner, and record whether the site is operating normally or under an approved containment plan. Keep the evidence in the system designated by the project; this article is a worksheet, not a substitute for that record.

If you are still defining what to request from a WMS vendor, start with the [WMS RFP template](/wms-rfp-template). If the new system also needs dimensioning data, the [WMS dimensioning integration playbook](/blog/wms-dimensioning-integration-playbook) covers that separate integration job.