On a new site, cutover is a question of whether the building can open. On a site that has been running classic WM for years, it is a question of whether the building can keep shipping while its brain is swapped. The racks are full. Orders are in the system. Customers have been promised deliveries for Monday and Tuesday and have no interest in your project plan. The general runbook decisions are covered in Cutover weekend, and the greenfield version of the go-live question in Big bang or phased for a new DC. This note is about what a live warehouse adds to both, as part of the wider WM migration work.
Stock that both systems must agree on.
A greenfield site fills up after go-live, so the system is the record from the first receipt. A brownfield site has thousands of handling positions already sitting in bins, and at the moment of switch the new system and the floor have to say the same thing about every one of them.
SAP provides migration tools for warehouse product data, storage bins and stock, and the data side is covered in Migrating WM data to EWM. The floor side is our concern here. A tool can carry a stock figure across faithfully and carry an error across just as faithfully. If a bin in WM says forty and the shelf holds thirty-one, EWM will start life believing forty, and the first picker to reach that bin finds out on a customer order.
So the count strategy is part of the cutover, not a separate stock-take project. Decide which zones get a full count before the freeze, which get a cycle count, and which are trusted because their history has earned it. Then agree who adjudicates a variance and what the tolerance is before anyone finds one at two in the morning.
Open work has to be closed before the freeze.
In a live warehouse the freeze always lands mid-flight. A pick is half done. A put-away is on a forklift. A replenishment was created an hour ago and nobody has touched it. SAP's guidance for migrating from WM is that open transfer orders should be finished or cancelled before the freeze, not counted on to carry across. Take that literally.
In WM terms that means transfer requirements and transfer orders, and in EWM terms it means warehouse requests, warehouse tasks and warehouse orders. They are not the same objects, and a task half-executed in the old model has no tidy equivalent in the new one. The clean answer is a quiet point: the last wave is picked and confirmed, put-away is cleared, replenishment is either done or deleted, and what remains is stock in bins and nothing in motion.
Getting to that quiet point is a floor job with its own schedule. Give it an owner, a checklist by area, and a time on the runbook. A site that treats it as a system task will find, on Saturday night, that the system says it is clear and the dock says otherwise.
Customers are still expecting deliveries.
This is the difference that surprises project teams most. Nobody orders less because you are cutting over. The outbound flow has to be managed down deliberately, weeks ahead, with sales and customer service in the room and not merely told.
That usually means agreeing a cut-off for orders that must ship before the freeze, pulling forward what can be pulled forward, warning key accounts about a slower first few days, and deciding what happens to orders that arrive during the weekend. It is a commercial conversation. The warehouse cannot have it alone, and the consultant cannot have it at all. If the first time customer service hears the date is in the go-live email, the project has already lost the first Monday.
The way back is a decision with a deadline.
Project plans often carry a line called fallback, and it usually implies that WM and EWM will run in parallel for a while. For the same stock, that is rarely realistic. Two systems cannot both hold the truth about one bin. Every movement made in EWM after go-live makes the old WM picture less true, and no team has the hours to key everything twice.
So treat fallback as a decision with a clock on it. Name the go / no-go point before the freeze, and name the point after which you do not roll back, because too much has moved to reverse it sensibly. Before that point, the plan is to restore the old state. After it, the plan is to fix forward, with people, not to agonise. Everyone who could pull the lever should know which side of the line they are on, and when the line was crossed.
Nobody runs two systems over one set of racks for long. Decide where the door to the old one closes, and say so before you are tired.
One warehouse at a time, if the business allows it.
Migration runs per warehouse number. For a business with several sites on WM, that opens a route a single-site business does not have: go warehouse by warehouse. Nothing forces it, and some businesses have reasons to move together, but where it is available it is worth serious thought.
The first site becomes the rehearsal for the rest. What you learn about count discipline, about the last-wave cut-off, about how the floor takes to the RF flows, is worth more than any workshop, and it arrives while the other sites are still stable on WM. Our APAC rollout case study covers a central EWM template rolled across ten warehouses in one market, where each site could learn from the ones before it. The cost is a longer period of two systems across the network, and the interfaces and reporting that go with it. That trade should be made in the open.
Rehearse it with real data.
A cutover on a live site should be rehearsed in full at least once with production-like data, and reconciled properly after each rehearsal. Not a walk-through of the runbook on a screen: the extract, the load, the stock comparison against what the floor actually holds, the open-work clearance, the first receipt and the first pick. Reconcile after every run and keep the differences list, because the second rehearsal should show that list getting shorter for reasons you can name.
A rehearsal is the cheap place to find what otherwise surfaces on the first shift: labels that do not scan, bins that do not match, a flow that looked fine in the test client. Our EWM rescue case study shows the far end of that list, a national operation that went live and could not scan at all.
The first shift on EWM.
Your operators are experienced. They know where the stock lives, which supplier pallets are always mislabelled and which aisle jams at ten in the morning. What they do not yet know is the new RF flows, and expertise in the old ones can make the change harder, not easier, because the hands move faster than the eyes read the new screen.
Put supervisors on the floor for the first shifts, not in the office. Make the project team visible and give them a job: stand at the bays, answer the questions, write down what is odd. Expect the exceptions, and tell the floor to expect them too. Labels that do not scan. Bins whose physical position does not match the system record. A handling unit nobody can find. None of that means the cutover failed. It means the floor is a real one, and the reason for the count strategy and the rehearsal is to keep those exceptions few enough to clear the same day. What happens after that first week is covered in Hypercare done early.
How Luminar approaches a live cutover.
We do not sell the build, so we have no interest in a cutover date that suits the plan and not the site. A senior consultant walks the floor early, looks at the stock reality, the open-work pattern and the outbound commitments, and writes down what has to be true before the freeze. Then we stay for the first shifts and stand at the bays. The point is to have someone in the room who has watched this weekend go both ways and has no reason to soften what they saw.