A template that has run in another country is a finished design. A template that has to run in ten of your warehouses is a programme, and the thing that decides whether it goes well is rarely the design. It is the order you do things in, and what you carry from one site to the next. Our note on big bang or phased for a new DC covers the single-site argument. This one is about the network question that comes after it.
What a rollout changes.
The APAC rollout we support is a central SAP EWM template, already proven elsewhere, landing across ten warehouses in one market. We make no claim about its results here, because the measured outcomes are still being finalised with the client. What we can describe is the shape of the work, and the shape is instructive.
On a rollout of that kind the risk is seldom the core design. It is the gap between a template signed off in head office and ten floors that were each set up, staffed and run differently. So the work is condensed and site-led. The template is the constant, each warehouse goes live in a phased sequence rather than in one big bang across the network, and on every site the same discipline applies. Map how the floor actually runs, find where the template and the operation disagree, and make a deliberate call on whether the system bends or the floor is retrained, before go-live and not during hypercare.
Sequencing is how you make that discipline affordable. Done in a sensible order, each site teaches the next one something. Done carelessly, each site repeats the last one's mistakes.
Choose the first site to learn.
The instinct is to start with the easiest warehouse, the small one with the friendly manager. That proves the template can run and tells you very little else. The better first site is one that will teach you the most without putting the biggest customer at risk.
In practice that means a site with enough of the template's processes in daily use to exercise the design: inbound, put-away, picking, replenishment, the exception paths. It means a site whose volume is real but whose service commitments can survive a rough fortnight. And it means a site with a floor leadership team that will tell you the truth, because the first go-live is where the template meets the country for the first time. The things it gets wrong there, local carrier labels, unit-of-measure habits, the way a shift handles a short pick, will turn up again at every other site.
Avoid the flagship, and avoid the site that has a known problem the programme secretly hopes the new system will fix. A first site should be a clean test of the template, not a rescue.
Group the rest into waves by similarity.
After the first site, the temptation is to sequence by geography, because the travel is easier, or by business unit, because the org chart says so. Neither is wrong, but similarity usually works better. Group sites by how they run: the ones that are mostly pallet in, pallet out; the ones with heavy each-picking; the ones that share a carrier mix or a customer with special labelling; the ones with automation or none.
A wave of similar sites lets one set of local decisions serve several floors. If the first pick-heavy site settles how the template handles a short pick, the next two pick-heavy sites inherit that answer instead of reopening it. A wave of mixed sites does the opposite: every floor needs its own set of conversations at the same moment, and the team stretches thin.
Waves also give the programme a natural rhythm. A wave is a unit you can plan, staff, rehearse and review as one thing.
Freeze one template version per wave.
A template that keeps changing while it rolls out is not a template. It is a different system at every site. The discipline that prevents this is to freeze a version for each wave: the sites in the wave go live on the same release, with the same configuration and the same master data conventions, and the change requests that arrive during the wave wait.
That raises the obvious question about fixes. Some will be real defects, and a defect that stops a floor working does not wait for the next wave. Agree the rule before the first go-live: what counts as a stop-ship fix that goes into a live wave, and what is queued for the next version. Everything else, the useful improvements and the local requests, goes in the queue with a name against it and a wave it is meant for.
Then check what earlier sites are running. When the template moves on, the already-live sites need to catch up on a plan, or the country ends up with several versions in production. Decide how that catch-up will be scheduled before the second wave, not after the fourth. Where a site needs something the global team should adopt, the route is in global template, local floor.
Carry people from site to site, not just documents.
The cheapest knowledge transfer in a rollout is a person. Key users from an earlier site, who have lived through a go-live and know where the template bites, are worth more on the next site than another set of slides. So is a small cutover crew that moves with the programme: the people who know the freeze, the stock count, the first receipt and the first dispatch because they have run them before.
This has a cost. Those people are away from their own floor, and their site needs cover. Plan it as a deliberate loan with a return date. Then use the same people for the training, because a shift lead is more convincing when the person explaining the scanner flow has done it on a live dock. The point about readiness in readiness is not training applies to every site in the sequence, not only the first.
Keep go-lives out of peak.
Every network has a calendar. The weeks around a major sale, a seasonal peak, a financial year end, a promotional launch: the floor is full, the casual labour is new, and any change in how the system behaves lands on people who have no spare attention. Putting a go-live there borrows risk from a period that already has plenty.
Lay the peaks on the programme plan before you place a single site. Leave a quiet gap before each one so the previous wave has settled, and leave another after it so hypercare is not competing with the rush. Two go-lives close together can look efficient on a Gantt chart. On the floor they mean the same senior people are in two places, and the second site gets what is left of them.
What the network does while a site is down.
A go-live is a short period in which one warehouse is slower than normal, or briefly not operating the way customers expect. On a single-site business that is the whole story. On a network it is a question the planning team can answer in advance.
Decide which orders the other sites can absorb, and for how long. Decide whether inbound is rerouted, held at the supplier or accepted and queued. Tell the customers with tight delivery windows early, and agree with the transport providers how bookings change across the cutover. Agree who has authority to move stock between sites and how that movement is recorded, so the transfers do not become the next count discrepancy. This is network planning work, not system work, and it belongs on the same plan as the cutover weekend. The weekend itself is covered in our cutover weekend runbook.
Site five should be easier than site two. If it is not, the programme is repeating itself, not learning.
Capture lessons while they are fresh.
After each go-live, hold a short review with the floor, the key users, the cutover crew and the template team. Do it within days, before the memory softens. Ask three plain questions: what surprised us, what did we have to work around, and what should the next site be told before it starts.
Write the answers into things the next site actually uses: the site-readiness checklist, the cutover plan, the training scenarios, the list of known template-versus-floor differences. A lessons-learned report that sits in a folder helps nobody. A changed checklist helps the next floor on the first day.
Over a few sites this is where the sequence pays off. The template-versus-floor questions become familiar, so the mapping work gets faster. The repeated decisions become standing rules. The surprises narrow to the things that really are particular to one building.
How Luminar approaches the sequence.
We are independent and we do not sell the build, so we have no reason to bend the sequence toward a vendor's resourcing or an integrator's invoice. A senior consultant spends a day on your floor, walks the candidate first site and a couple of the later ones, and reads the template against what the floor actually does. Then we write a plain-language memo within five working days: which site should go first and why, how the others might group, where the peaks sit, and the decisions the programme still owes the floor. No proposal is attached.