WMS Selection: A Vendor-Neutral Guide to Choosing a Warehouse Management System
WMS selection advice is often published by companies that sell warehouse software, and criteria written by a seller carry the seller's interest. Everest sells no software of its own, so this guide is written to help you reach a defensible decision, including the decision not to buy anything at all.
- Software Everest sellsNone
- Licence margin on any platformNone
- Manhattan AssociatesPlatinum partner
- Infios (formerly Korber)Certified partner
Ask any advisor for this in writing.
Start With the Right Question: Replace, Upgrade, or Fix the Process
Replace a warehouse management system when the constraint is the software model itself, and upgrade or re-implement when the constraint is the version, the configuration, or the process running on top of it.
Replace
- The operating model has changed structurally, for example a distribution-only network now running store fulfillment, direct-to-consumer parcel, and returns through the same building
- The vendor has ended investment in your product line and the roadmap you depend on lives in a different product
Upgrade
- The capability exists in a current release you cannot reach because of undocumented customizations and a version gap
Re-implement
- The software is capable but the original configuration encoded a business that no longer exists
Fix the process
- Inventory accuracy, slotting discipline, or master data quality would break any system you install
Treat a business event, an acquisition, a new site, a third-party logistics (3PL) transition, or an ERP migration, as a forcing function for the decision rather than as the answer to it
Write Requirements That Actually Differentiate Vendors
Most WMS requirement lists fail to separate vendors because the majority of the lines describe capabilities every established system already has, such as receiving, directed putaway, radio frequency (RF) picking, cycle counting, and shipping confirmation.
- Order streaming model
- how the system handles waveless or continuous release against traditional wave planning, and what happens when a hot order arrives against an open allocation
- Inventory attributes
- lot, serial, expiry, catch weight, country of origin, and grade, and whether allocation rules can act on all of them together
- Automation boundary
- what the WMS controls directly versus what it hands to a warehouse execution or control layer, because this line decides the size and shape of your integration scope across every release that follows
- Extensibility model
- whether your differentiation is built as supported configuration and extension, or as code that a future release will fight
- Multi-node and multi-channel behavior
- store fulfillment, direct-to-consumer parcel, wholesale, and returns disposition running concurrently in one building
- Labor standards and engineered standards
- whether the system supports the labor model you want to manage to, or only reports what already happened
- Billing and client segregation if you are a third-party logistics provider, where activity-based billing and client-level data separation are structural, not add-ons
Warehouse Management System Selection Criteria Buyers Under-Weight
The WMS evaluation criteria buyers most often under-weight are the extension and upgrade model, the integration surface, data migration effort, and the support model, because none of them show up in a demo but all of them determine what the system costs to own.
- Extension model and upgrade path what is configuration, what is supported extension, what is custom code, and who re-tests each category when a release lands
- Integration surface the number of interfaces, which are event-driven versus batch, peak message volume, and whether the vendor charges for middleware or integration platform capacity
- Data migration reality item master, locations, inventory positions, open orders, and history, plus who reconciles inventory when the numbers do not tie
- Test coverage and regression whether you can automate regression, and how often the vendor’s release model forces you to run it, since the answer differs sharply between versionless and release-based platforms
- Support model what the vendor covers, what a second-line (L2) and third-line (L3) support partner covers, what your team owns, and where the boundary sits during unattended shifts and peak volume
- Partner bench depth on your chosen platform, in your region, with named people rather than logos on a slide
- Floor usability and exception handling how many taps an associate needs for the exception that happens hundreds of times a shift, not the happy path shown in the demo
- Rollout blast radius whether the system can be deployed site by site or wave by wave with a clean checkpoint and a rollback point at each step
Total Cost of Ownership: The Components That Appear After Signature
The software subscription is usually a minority of total WMS cost, because integration, extensions, data migration, testing, hardware, training, and ongoing support together typically exceed the subscription across total cost of ownership.
- Subscription or license, with the pricing metric stated explicitly and modeled against your growth, seasonality, and acquisition plans
- Non-production environments for development, test, training, and performance, priced individually
- Integration build and the middleware or integration platform that carries it, including capacity charges
- Extension development plus the standing regression effort each release requires afterwards
- Data migration, cleansing, and inventory reconciliation, which is effort your team supplies as well as the partner
- Hardware and peripherals radio frequency (RF) devices, printers, label stock, scanners, network coverage in racking, and print server capacity
- Training, super-user development, and change management for every shift, including seasonal staff
- Elevated post-cutover support and ongoing managed support, whether from the vendor, a partner, or an internal team you have to hire and retain
- Internal cost the operations and IT people pulled onto the program, and the backfill for their day jobs
- Exit cost data extraction, format, and the integration rework a future move would require
How to Test a Vendor Claim Instead of Believing It
Test a vendor claim by making the vendor run your data, your exceptions, and your heaviest day in a scripted demonstration that you wrote, because a demo written by the vendor only proves the vendor can demo.
- Write the demo script yourself, send it in advance, and require the vendor to use your item master, order profile, and exception cases
- Score the demo against the written scenarios, with the same scorers present for every vendor, and record the score before discussion
- Ask of every yes generally available or roadmap, configuration or code, which release, and how many production customers at a comparable profile
- Request references that match your operating profile, not the vendor’s strongest reference, and ask them what they would scope differently
- Insist on named implementation people with named prior go-lives, and make continuity of that team a contractual expectation
- Run a proof exercise on your own master data where the decision is close, because master data reveals assumptions that clean demo data hides
- Ask how the vendor handles a failed release or a defect found in production, and what the rollback path looks like
- Convert the winning scenarios into contractual acceptance criteria so the demo you bought is the system you get
Running a WMS RFP That Produces a Decision You Can Defend
A WMS RFP works when it is scored on weighted, testable requirements and a fixed scenario set, and it fails when it is a long list of yes and no questions that every vendor answers identically.
- State the operating context first sites, channels, order profiles, SKU counts, automation, seasonality, and the systems the WMS must integrate with
- Attach the scenario set and the demo script as scored sections, not as background reading
- Set weights and scoring rules before responses arrive, and register them with the steering group
- Use one fixed cost template for every bidder, covering every total cost of ownership component from subscription through exit cost
- Score software and delivery services separately, and allow the answers to differ
- Require named team members, reference customers at a comparable profile, and the vendor’s own assumptions about your effort
- Record why each rejected option was rejected, in writing, at the time of the decision
Blue Yonder, Infios, Manhattan Associates, and SAP EWM, Described Factually
There is no single best warehouse management system, because Blue Yonder, Infios, Manhattan Associates, and SAP Extended Warehouse Management are each defensible choices for a different operating profile, and the correct answer depends on your network shape, automation footprint, and enterprise systems environment.
| Product line | Delivery model | Extension and release model | What to verify yourself |
|---|---|---|---|
| Blue Yonder | An established warehouse management product line delivered through the vendor’s cloud platform. | Functional footprint documented in Blue Yonder’s own product literature. | Which capabilities are generally available in your target release, and how many production customers run a comparable profile. |
| Infios (formerly Korber) | A product range covering several tiers, so the tier is matched to site complexity. | The tier sets the extension and upgrade path, so it differs across a mixed environment. | Which tier each of your sites is quoted on, and what moving between tiers later involves. |
| Manhattan Associates | Manhattan Active® Warehouse Management, documented by Manhattan Associates as cloud-native and versionless. | Microservices with a documented extension framework; platform updates land continuously. | What your extension surface becomes under continuous release, and who re-tests it each time. |
| SAP Extended Warehouse Management | Available embedded in S/4HANA or deployed decentrally. | Release and extension model follows your wider SAP environment rather than the warehouse alone. | Whether embedded or decentral fits your network shape, and what that choice costs later. |
Tier fit matters more than brand: a single-site operation with modest automation and a global network with robotics, store fulfillment, and third-party logistics (3PL) clients are not shopping in the same market.
Why Structural Neutrality Matters, and Where Everest Stands
Neutrality in WMS selection is structural rather than attitudinal, because an advisor that sells its own warehouse platform, resells a license, or earns a margin on the software cannot give you a recommendation with nothing riding on the outcome.
Ask this of any advisor
- Ask every advisor whether they sell, resell, or earn margin on any platform in your evaluation, and get the answer in writing
- Separate the selection engagement from the implementation engagement contractually if you want the advice to stay independent
Everest’s own answer
- Everest sells no software of its own, so a platform recommendation carries no license interest
- Everest is a Manhattan Associates Platinum Partner, a 2-time Manhattan Partner of the Year (Commerce Services 2022, Collaboration Excellence 2023), and a certified Infios (formerly Korber) implementation partner with 50+ certified Infios associates
- Everest delivery evidence: 300+ WMS go-lives since 1997, 150+ Manhattan Active® go-lives, 65 of them across 2024 to 2025, 150+ enterprise clients, and 885+ team members across 17+ countries
- Five practices, Supply Chain, Retail, Data Engineering, Quality Engineering, and AI, sit behind a selection review, so integration, data, and test questions are answered by the people who do that work
Verify our Manhattan partner status See all platform partnerships
Frequently Asked Questions
Choose a WMS in four steps. First decide whether your constraint is the software, the version, or the process. Second, write 10 to 15 scenarios from your own operation where vendors genuinely differ. Third, score a demo you scripted using your own data. Fourth, price every cost component, not the subscription alone.
The criteria that decide outcomes are the extension and upgrade model, the integration surface, data migration effort, automation boundaries, floor usability for exceptions, and the support model. Functional coverage matters less than buyers expect, because established systems overlap heavily on receiving, putaway, picking, counting, and shipping. Weight the invisible criteria explicitly in your scorecard.
Replace when your operating model has outgrown the software model itself, or when the vendor no longer invests in your product line. Upgrade or re-implement when the capability exists in a current release you cannot reach because of undocumented customizations. If inventory accuracy or process discipline is the real problem, no new system fixes it.
Selection effort is governed by scope rather than by a calendar. The variables are the number of sites, the number of channels and order profiles, the automation footprint, how many integrated systems exist, and how much requirement documentation is already current. Size those first, and the selection plan follows from the scope you actually have.
A WMS RFP should include your operating context, a scored scenario set, a demo script, weighted requirements agreed before responses arrive, one fixed cost template every bidder completes identically, references at a comparable operating profile, named delivery people, and a separate score for software and for implementation services. Record why each rejected option lost.
No single warehouse management system is best for every operation. Blue Yonder is an established product line delivered through the vendor’s cloud platform, Infios covers several product tiers, Manhattan Active® Warehouse Management is cloud-native and versionless, and SAP Extended Warehouse Management fits SAP-standardized environments. Fit depends on network shape, automation, and channel mix.
Total WMS cost includes subscription or license, non-production environments, integration build and middleware, extension development and its standing regression testing, data migration and inventory reconciliation, radio frequency (RF) hardware and printers, training across every shift, elevated post-cutover support and managed support, internal staff effort, and eventual exit cost. Subscription alone is usually the minority share.
Yes. Everest sells no software of its own, so a platform recommendation carries no license interest. Everest implements Manhattan Active® and Infios, and will say plainly where its hands-on evidence is deepest. If your requirements point to a platform Everest does not implement, that is a valid outcome of the review.
Want a Second Opinion on Your Shortlist?
Everest sells no software of its own, so a selection review carries no license interest. Tell us your network shape, channels, and automation footprint, and we will tell you plainly where the evidence points.
Request a Selection Review