WMOS to Manhattan Active: what changes for your DC team
Moving from Manhattan WMOS to Manhattan Active WM is often planned as an IT upgrade. For the people running the floor, it changes how work is released, done and fixed. These are the changes supervisors and DC managers notice first, and how to prepare them.
1. Updates arrive every quarter
On WMOS, upgrades were projects years apart. Manhattan Active is updated continuously, with new releases every quarter. That means operations needs a standing rhythm: read the release notes, test the core flows, sign off. Teams that treat this as routine stay calm. Teams that treat each release as an event burn out.
2. Customisations become extensions, or go away
Modifications built into the WMOS core do not carry over. Each one is mapped to standard configuration, rebuilt as an extension, or retired. Every retired customisation changes a process somebody on the floor knows by heart. Walk supervisors through those changes before go-live, not during the first shift.
3. New screens, same pressure
Handheld and desktop screens change, and so do some task flows. Train by role, using your own items and locations rather than demo data, and test every device and printer model early. The pick rate in week one depends on it.
4. Interfaces and exceptions get new owners
Integration on Manhattan Active is API-led. Error handling changes with it. Decide who watches the interface queues, who fixes a failed ASN, and how fast, before the first trailer arrives.
5. Data has to be clean on day one
Item master, locations and open inventory move at cutover. Bad dimensions or duplicate locations show up immediately as failed allocations and short picks. Clean the data in the months before, not the weekend of.
Before your first site goes live
- A list of every retired customisation and the process it changes
- Role-based training on your own data
- Every device and printer model tested
- Named owners for each interface and error queue
- A regression pack ready for the first quarterly release