DigiAutomateDigiAutomate
Manhattan Active WM · 43 checks · 7 sections

Cutover readiness checklist.

Free, no sign-up, no email address asked for. Written from general warehouse-management delivery experience and publicly known Manhattan Active WM concepts, and it scores against the same 7 dimensions the paid Cutover Readiness Review uses. Nothing here is taken from any programme's records or from vendor documentation. Print it, take it into your next steering meeting, and count the ones nobody can answer.

43 checks · Discovery and scope · Configuration governance · Interface contracts · Master data · Test readiness · Cutover · Hypercare

How to use it

Go down it with the people who own the answers, not on your own. Every item is either evidenced, owned with a date, or a blocker — there is no fourth state, and "in hand" is not one of them. The items that nobody can answer in the room are the ones that will find you later.

Section 01 · 6 checks

Discovery and scope

  1. 1.1Name the sites, buildings and waves in scope — and, in the same document, the ones that are out.Scope that is only implied gets re-argued during UAT, which is the point at which changing it costs the most.
  2. 1.2Capture process variants per site, not per company.Two warehouses said to run the same process almost always differ in receiving, putaway and packing, and the differences arrive as test scripts nobody wrote.
  3. 1.3Record real volumes: order lines a day, peak day, units per line, order profile.Sizing, wave design, equipment counts and labour standards all trace back to these, so a guess here is a guess everywhere downstream.
  4. 1.4Agree who decides fit-gap outcomes, and how, before the first workshop.A fit-gap log with no named decision owner turns into a list of opinions and stalls at the first genuine conflict.
  5. 1.5Close every open fit-gap item with a dated decision, or with a named owner and a due date.The unknowns are exactly the items that reappear as change requests in the last four weeks before go-live.
  6. 1.6Split day-one scope from the wish list in writing, and have the sponsor agree the split.Without that split everything is day-one scope until the plan is visibly late, and then the cut is made in a panic.
Section 02 · 6 checks

Configuration governance

  1. 2.1Keep one controlled record of configuration per environment, and make changing it a deliberate act.Configuration that exists only inside environments cannot be compared, so drift is discovered in the worst environment at the worst time.
  2. 2.2Name an owner for each configuration area — inventory, receiving, allocation, packing, shipping, labour.An area with no owner gets configured three ways by three people, and all three are defensible in isolation.
  3. 2.3Make configuration promotion between environments repeatable and logged, not manual re-keying.Re-keying by hand is how configuration that passed test reaches production subtly different from the version that passed.
  4. 2.4Freeze configuration before each test cycle and publish the freeze date.Config changed mid-cycle invalidates the tests that already passed, and in practice nobody re-runs them.
  5. 2.5Record the reason beside every deliberate deviation from standard behaviour.A year later nobody can tell a considered deviation from an accident, so nobody dares touch either.
  6. 2.6Reconcile production configuration against the tested baseline before go-live, item by item.The gap between "we configured it" and "it is configured in production" is where go-live nights are lost.
Section 03 · 7 checks

Interface contracts

  1. 3.1Inventory every interface with direction, trigger, frequency and volume — including the ones that only run at period end.The forgotten interface is always found by the business, in production, on the day it was due to run.
  2. 3.2Agree a field-level mapping per message, signed by both sides. A diagram is not a mapping.Two boxes and an arrow is not a contract, and the fields are precisely where the argument is.
  3. 3.3Define what happens to a rejected message: who sees it, where it queues, who clears it, within what time.Error handling designed after go-live means failures sit invisible until the stock position is already wrong.
  4. 3.4Agree retry, idempotency and replay behaviour for each interface.Without it a replayed confirmation double-counts, and once the numbers have been wrong once nobody trusts them again.
  5. 3.5Pin down units and formats: unit of measure, quantity precision, date and time zone, country and currency codes.Unit and time-zone assumptions are the classic silent corruption — everything looks fine until somebody reconciles.
  6. 3.6Test interfaces against the real middleware and the real endpoints before UAT closes, not against stubs.A stub proves your side works. It proves nothing at all about the other party.
  7. 3.7Agree cutover-day interface sequencing: what is switched off, what is queued, what is replayed and in what order.Interfaces started in the wrong order during cutover are the most common cause of a clean plan producing dirty data.
Section 04 · 6 checks

Master data

  1. 4.1Name an owner for each master data domain: item, location, carrier, customer, vendor, unit of measure.Unowned data gets cleansed by whoever happens to be free, which is nobody, twice.
  2. 4.2Set a quality target for item dimensions and weights and measure against it. Do not assume the ERP is right.Cartonisation, slotting and shipping rate selection all fail quietly when dimensions are wrong.
  3. 4.3Prove the location model against the actual building — aisle, bay, level, zone, pick face.A location master built from an old drawing sends pickers to bins that do not exist, on day one, in front of everyone.
  4. 4.4Decide which system owns each attribute, and stop the other one writing it.Two masters for one attribute means the value depends on which load ran last, which is not a rule anyone can operate.
  5. 4.5Run the data cleanse as a tracked workstream with a burndown, not as a line on somebody else's plan.Data cleanse is the most under-planned item on most programmes, and it is the one thing that cannot be compressed at the end.
  6. 4.6Rehearse the data load end to end at production volume, including the reconciliation and the sign-off.A load that works for five hundred items tells you nothing about two hundred thousand, and the cutover window is measured in hours.
Section 05 · 6 checks

Test readiness

  1. 5.1Write test scripts from the process variants, with expected results, before the cycle opens.Testing without expected results is demonstration, and demonstration passes everything.
  2. 5.2Include the failure paths: short picks, damages, returns, cancellations, partial shipments, re-prints.Happy-path testing finds nothing, because the happy path is the part that was always going to work.
  3. 5.3Test on the RF and voice hardware that will be used in the building, not on a desktop emulator.Signal, scanner behaviour, gloves and screen size all break flows that passed comfortably on a laptop.
  4. 5.4Run at least one volume test with realistic wave sizes and concurrent users.Performance problems only appear under concurrency, and if they do not appear in test they appear on the first busy day.
  5. 5.5Track defects with severity, owner and a retest step, and state exit criteria as numbers."Nearly there" is not an exit criterion, and it is said four weeks running by people who mean it.
  6. 5.6Have the people who will actually operate the system run UAT, on scripts written in their words.Superusers testing on behalf of the floor hide every usability problem that later costs throughput.
Section 06 · 6 checks

Cutover

  1. 6.1Build the cutover plan as a timed, sequenced runbook with owners, durations and dependencies.A plan written by day rather than by hour cannot tell you at three in the morning whether you are late.
  2. 6.2Define the inventory freeze, the last-transaction point in every feeding system, and who enforces them.An un-agreed freeze means the load is reconciled against a moving target, and the variance is never fully explained.
  3. 6.3Rehearse cutover at least twice, with the second rehearsal timed and using the real load files.The first rehearsal finds the sequence errors; only the second one tells you whether the timings are real.
  4. 6.4Write the go/no-go criteria, the decision time and the name of the person who decides.Without a stated hour and a named decider, no-go is not genuinely available, so the decision gets made by drift.
  5. 6.5Write the rollback: how long it takes, who calls it, and the point after which it is no longer possible.A rollback nobody has costed is a rollback nobody can call, which means the only option left is to push on.
  6. 6.6Agree how work in flight at the freeze is handled, per document type — open orders, receipts, shipments, returns.In-flight work is where day-one confusion actually comes from. It is very rarely the new screens.
Section 07 · 6 checks

Hypercare

  1. 7.1Staff hypercare by shift, in the building, across the hours the operation actually runs.A support model that stops at five is not support for a site that is still shipping at ten.
  2. 7.2Publish one route for raising issues, with triage and severity definitions, from day one.Three message groups and a mailbox mean the same issue is worked three times and the serious one is missed.
  3. 7.3Watch a small set of operational numbers daily: units shipped, lines picked, late orders, interface errors, stock adjustments.Without a baseline from the first days you cannot tell recovery from slow decline, and both feel the same in the room.
  4. 7.4Keep one list of open items with owners and a weekly cut, and review it with the sponsor.Hypercare issues that never reach a list become permanent workarounds by about week three.
  5. 7.5Agree hypercare exit criteria and the handover into business-as-usual support before go-live, not during it.Hypercare with no exit quietly becomes the support model, at project rates, for as long as nobody says otherwise.
  6. 7.6Capture the workarounds people invent in the first fortnight and decide which ones become configuration.An undocumented workaround is the real process within a month, and it will not be in any training material.

If you want it scored

The checklist is the method. The paid review is somebody applying it to your programme's own artefacts and writing down what they find.

The Manhattan Active WM Cutover Readiness Review is £3,000 fixed: a readiness score across these 7 dimensions, a written blocker list with owners and severity, and a recommended sequence to go-live. Document-based and remote, about 3 weeks, no production access needed. Send a line about your go-live and you will get a straight answer about whether it would help.

Also on this site: the schema catalogue extract — 89 entities and 2,307 fields, published as evidence of the depth this work is done at.