It happens more often than anyone admits. A programme ends, a contract lapses, a key consultant takes another job, or the relationship simply sours. The warehouse is live, the trucks are still arriving, and the person now responsible for the system was not in the room when any of it was decided. If that is you, this note is about the next few weeks. It sits in our SAP EWM health check and optimisation work, and it starts from a plain position: you have inherited a system, not a verdict.
Blaming the previous team is easy and rarely useful. Sometimes they made poor calls. More often they made reasonable ones under a deadline, for a business that looked different then. What you need is an accurate picture of what exists and why, and you need it before the people who hold that picture walk out the door.
What a takeover actually is.
Our EWM rescue is the reference point here. Luminar was engaged after go-live, not as the build team, and the relationship with the original team had broken down. The brief was narrow: stabilise the operation, find out what was actually wrong, and give the business a path forward it could trust. We did not own the original build and we did not claim it. That framing applies to any takeover. Your first job is not to improve the system. It is to understand it well enough that your next decision is an informed one.
Understanding has two halves that rarely line up: what the documents say was built, and what is actually configured and running. The gap between them is where most of the surprises live.
What to ask for before the old team leaves.
If you still have access to the people who built it, treat their remaining time as the scarcest resource in the programme. Ask for the following, in writing, and ask for the reasoning as well as the artefact.
Design documents, and the truth about them.
Ask for the design documents, then ask which parts no longer match what is configured. Every document set drifts after go-live because fixes go in under pressure and nobody goes back to the paper. An honest answer is "section four is out of date and here is what changed". A blank look tells you how much weight to put on the binder.
The custom code list, with a reason for each object.
Get a complete list of every custom object, and beside each one the business reason it exists. The reason is the valuable part. An object with a clear reason can be judged on its merits. An object nobody can explain is a risk you now own. Our note on the cost of Z code covers how to weigh that list once you have it.
Interfaces and background jobs.
List every interface in and out of the warehouse system, who owns the other end, and what happens when one stops. List every scheduled background job with its timing and what depends on it. These are the things that fail overnight and show up as an empty pick list at the start of a shift.
Open defects and workarounds.
Every live system has a list of known problems and the informal fixes people use around them. Ask for both. A workaround that lives only in one supervisor's head leaves with that supervisor.
Test scripts, transport history and the key user list.
Test scripts show what the team thought mattered. Transport history shows what changed and when, which is often the fastest way to explain a behaviour nobody remembers deciding. The key user list tells you who on the floor and in the office actually knows how a process behaves, and those people are worth more than any document.
The first 30 days: watch, do not change.
The instinct on day one is to act. Resist it for a month. The system has been carrying real work since go-live, and a large change made without understanding it is how an unstable site becomes a broken one.
Spend the time on the floor. Stand at the dock, at a pack bench and at a replenishment point on a busy shift, and watch what operators do when the scanner and the process disagree. That gap is the subject of our note on system versus reality, and in a takeover it is your best map.
Then read the warehouse monitor, /SCWM/MON, as a routine. Look at what is sitting in queues, what is stuck, what is aged and what clears itself. A monitor that someone clears by hand every morning is telling you about a process that does not finish on its own.
Keep a running list of what breaks and, for each item, who fixes it today. The second column matters more than the first. If the answer is a named person on the old team, you have a dependency to replace. If the answer is "whoever notices", you have a gap. If the answer is "the floor, by hand", you have a workaround that has become process. By the end of the month you should have a single list of faults, owners and workarounds that the whole business can read.
Built wrong, or built right for a business that has changed.
This is the distinction that keeps a takeover honest. Two things look identical from the office: a design that was wrong from the start, and a design that was right for the operation of three years ago. Both produce workarounds. Only one is a fault.
A typical pattern: a pick process designed around one customer profile, and an order mix that has since shifted. Or a put-away rule built for a smaller pallet range that now includes lines nobody planned for. The build team did the job they were given. The job moved.
The test is to ask what the design was meant to do and whether that intent still describes the warehouse. If the intent was sound and the business has moved, the answer is an adaptation, often small. If the intent was never right for the floor, that is a defect in the design, and it needs a proper fix. Telling these apart stops you spending a design budget on a configuration change, or the other way round.
Deciding what to fix, keep or retire.
Once you have the list, sort every item into one of three piles. Fix what is wrong and costing the floor time or accuracy today. Keep what works, including the parts you find ugly, because ugly and working beats elegant and untested. Retire what nobody uses: the dead custom objects, the interfaces to systems that have gone, the jobs that run and produce nothing.
Order them by what the floor feels. A fault that makes operators reverse and rescan every shift comes before a tidy-up that only the support team will notice. The rescue case worked the same way: the first gains came from the faults the floor was living with, and the business was given a path forward rather than a wish list. For what comes after the early fixes, see hypercare done early and the note on EWM support after hypercare.
The trap of rebuilding everything.
A new owner often wants to put their own stamp on the system. It feels like taking control. It is usually the costliest choice on the table, because a rebuild throws away the working parts along with the faulty ones and restarts the risk clock on a warehouse that is already trading.
Every part of the existing build carries knowledge about your operation, including the odd rules that exist because of a customer, a carrier or a dock constraint nobody wrote down. Rip it out and you pay to rediscover each one, usually on a live shift.
Your job is to understand the system well enough to change it safely, not to prove it was built by someone else.
There are cases where a redesign is right. When the evidence says the foundations do not fit the operation, you will know, because the list from the first 30 days will say so in specifics rather than in frustration. Even then, change it in pieces the floor can absorb, with the same care you would give any live cutover.
How Luminar approaches a takeover.
We are independent and we do not sell the build, so we have no reason to tell you the system needs replacing. A senior consultant spends a day on your floor, reads the system against what the operators actually do, and writes up what is working, what is broken and what is merely different, in plain language, in a memo within five working days. You can take it to your internal team, to the original integrator or to us. No proposal is attached.