For a business weeks away from going live on SAP EWM, whether it is a new distribution centre, a move off SAP WM or a group template landing on an Australian site. This page covers the readiness checklist, the cutover weekend, the go/no-go call and the rollback trigger, the first shifts, and when hypercare is really over. The status report can be green while the floor is not ready. This is how to tell the difference while there is still time to act.
Readiness · Cutover · Hypercare
The position. The date is set, the integrator's status report is green, and somebody on the floor is not convinced. Most go-lives that go badly were reported ready. The gap is nearly always the same: readiness was measured in configuration signed off and training completed, and nobody checked whether a real shift could run on the system without the project team holding it up.
How we work. A senior consultant on your floor before the go/no-go meeting, reading the test results, the cutover plan and the operation against each other. We do not sell the build or the support contract, so the read is about your warehouse and nothing else. If the site is ready, we say so. If it is not, we say what has to close and how long that will take, while the date can still move.
Every bin, quantity and handling unit the floor will see on Monday comes from the load. The product master needs dimensions, weights, units of measure and packaging specifications that match the cartons on the racking, not the ones in the old system. Ready means the opening balances have been counted or reconciled on a method everyone agreed, and the master data has been checked against the steel.
Go deeper · Product master data model for a new warehouse · Migrating WM data to EWM
Receiving, put-away, replenishment, picking, packing and loading, run on the real scanners by the people who will run them, with the short pick, the damaged carton and the missing label thrown in. A test script that only covers the happy path proves the configuration works. It says nothing about whether the shift will.
Go deeper · Testing a first WMS · The RF flow is the product
Training completion is the measure most programmes report and the one that tells you least. The test is whether a supervisor on the night shift can clear an exception without phoning the project. Readiness is proven on the floor, and the people who own the system on your side have to be named and in the room well before go-live week.
Go deeper · Readiness is not training · The team you need on your side
The site readiness nobody owns until go-live morning. Do the scanners read the symbology on the labels you actually print? Is there wireless coverage at the back of the cold room and on the mezzanine? Are the label printers at the dock, configured and stocked? Our rescue reference went live without a floor that could scan, and none of it was a system defect.
Go deeper · When the floor cannot scan
A go-live that lands just before a peak leaves the floor no time to settle and the hypercare team no slack. Decide in advance how the warehouse runs if a critical interface fails, what the manual fallback is, and whether the site goes live in one move or in phases. Then check the date against the trading calendar, not just the project plan.
Go deeper · Big bang or phased go-live · Where the warehouse sits in an S/4HANA programme
A full physical count, cycle-count sampling, or a system-to-system reconciliation. Each costs something different, and the right choice depends on how much the old stock record has earned your trust. Agree the variance rule before anyone finds a variance at 2am on Sunday.
Go deeper · SAP EWM cutover plan: the weekend runbook
Part-received deliveries, part-picked orders, stock on a truck between sites. Each category gets one of three answers: close it before freeze, migrate it in flight, or park it on a controlled list and re-enter it on Monday. On a WM site moving to EWM, open transfer orders should be finished or cancelled rather than counted on to carry across.
Go deeper · Cutting over a live warehouse from WM to EWM
A short list of hard gates, written down and agreed before anyone is tired: stock accuracy above the threshold, open transactions resolved or listed, critical interfaces confirmed live, the first shift staffed. One named person makes the call against the list. A no-go on the evidence is a professional decision, and the person making it needs explicit cover to make it.
Go deeper · The go/no-go section of the runbook
Separate from go/no-go: the specific condition, agreed in advance, that sends the floor back to the old process after go-live. Name who can pull it and how long they have to decide, because the window closes quickly once stock has moved under the new system.
Go deeper · The rollback trigger
Senior people at the bays, not in a control room. The questions that stall a floor on day one are small and local, and they get answered fastest by someone standing next to the operator. Rehearse the escalation path so a problem at one dock door never becomes a queue at one person's phone.
Go deeper · When the floor cannot scan
Labour per pallet back near the baseline, peaks running without overtime, defects and tickets falling week on week, no master data corrections waiting for an owner. Hypercare that ends because the contract says week six usually ends before the first month-end close and the first real peak, which is where the hard problems surface.
Go deeper · Hypercare done early
On a global template rollout the people who built the system may be eight hours away when the Australian floor opens. Hypercare has to be designed for that gap: who on site can fix what, and what waits for Europe to wake up.
Go deeper · Hypercare when the build team is in Europe
Choose the support model before the integrator rolls off, not after. Response times have to match the shift pattern rather than office hours, and the improvement backlog needs a home outside the incident queue.
Go deeper · Who owns EWM in year two
Overtime creeping back onto ordinary days, workarounds spreading, a ticket mix that has shifted from bugs to how-do-I questions. A go-live that ended badly rarely announces itself in month one. It shows up as drift, and a baseline captured before go-live is what lets you prove it.
Go deeper · Labour drift: the six-month signals · Stock accuracy after go-live
A site moving from no warehouse system onto SAP EWM through the Knauf global template, with Luminar as the local conduit to the German build team. Outbound peaks ran up to 30% higher with no overtime and no Z-code workarounds.
A national operation went live with another team and the floor could not scan: wrong barcode symbology, hardware tethered to fixed points, a reflective cover over the labels. Luminar stabilised it within 90 days and improved scalability by roughly 70%.
When the floor can run a real shift on the new system without the project team holding it up. In practice that means opening stock counted or reconciled on an agreed method, every flow tested end to end by the people who will run it, a key user on every shift, scanners and printers proven on the actual labels, and a written fallback. A green status report on configuration and training is not the same thing.
One named person from the business, usually the operations or supply chain lead who owns the outcome, deciding against a list of gates agreed in advance. The integrator and the project team give evidence. They should not be the ones deciding whether the warehouse is ready to open.
Anything that means the first shift cannot receive, pick and despatch: opening stock that has not been reconciled, a critical interface that has not been proven, scanning that fails on the real labels, or no trained people on a shift. A late defect list on its own is rarely the reason. The question is whether the floor can work around each item safely for a fortnight.
Avoid it where you can. A new system needs normal-volume weeks for the floor to settle, and the hypercare team needs slack to fix what surfaces. If the date cannot move, plan extra floor support, a narrower first-week scope and a tested fallback, and agree in advance what would trigger a rollback.
Until measurable exit criteria are met, not for a fixed number of weeks. Plan for it to cover the first month-end close and the first real peak, and taper the senior presence one responsibility at a time as the floor team shows it can carry each one.
If the trigger was defined in advance, the floor returns to the old process under a plan: who decides, what data comes back, and how stock moved under the new system is reconciled. If it was not defined, most teams do not roll back. They limp, and the cost shows up for months. Write the trigger down while the room is calm.
Yes, and that is when it is most useful. We do not sell the build or the support contract, so we can read the test results, the cutover plan and the floor against each other and tell the sponsor plainly what is ready and what is not, with time left to act on it.
One day on your floor and a plain-language memo within five working days: what is ready, what is not, and what has to close before go-live. No proposal attached.