Configurable is the most agreed-upon word in a WMS evaluation. Every platform on your shortlist has it, every vendor means something slightly different by it, and none of that tells you what you need to know.
Configuration covers the options the vendor already built. It says less about the first time a client asks for a workflow nobody anticipated, which is often where the real cost of the next few years gets set. You know how that goes: a ticket goes in, the estimate comes back in months with a change order attached, and the reply includes the phrase “this will require custom code.” Custom code solves the immediate problem. It also tends to bring vendor dependency and a development backlog, and it can make future upgrades more complex.
A recent Logistics Viewpoints analysis, highlighting insights from ARC Advisory Group’s Warehouse Management Systems Market Map, draws the line most evaluations skip. A configurable WMS and an extensible, low-code WMS are not the same thing. Here is what separates them, why the difference surfaces during a cloud migration, and the questions that get a straight answer out of a demo. We have put those questions on a one-page evaluation sheet you can print and score during the demo.
This article builds in part on “The End of Rigid WMS Deployments: Configuration vs. Low-Code,” published by Logistics Viewpoints and highlighting insights from ARC Advisory Group’s Warehouse Management Systems Market Map.
WMS configuration vs. customization vs. low-code extensibility
Everyone talks about adaptability. Architecture determines how adaptable your WMS actually is. Most evaluations collapse this into one word. It helps to separate three, because they carry very different costs:
- Configuration. Change predefined rules and settings inside the options the vendor already built.
- Low-code extensibility. Build or extend capabilities through an abstraction layer, without changing the core.
- Custom code. Develop functionality through conventional coding, which can introduce greater upgrade and maintenance complexity.
Configuration lets you change what the vendor anticipated. Extensibility lets you address what they didn’t.
Custom code addresses it too. Historically that is what buyers ended up paying for, and paying for again at the next upgrade. The distinction changes what an evaluation is measuring. It moves the question from how much the software can do to what happens at the edge of what it was built to do, and which of the three routes you take to get there.
What’s the difference between WMS configuration and customization?
Configuration changes predefined rules and settings inside options the vendor already built. Custom code develops new functionality through conventional programming, which can add upgrade and maintenance complexity. Low-code extensibility sits between them, building new capability through an abstraction layer above the core, so extensions stay more isolated from core changes.
What configuration actually covers
Rule-based configuration is the layer most warehouse teams live in every day, and it does real work.
It’s the warehouse manager setting FEFO ahead of FIFO for a perishable SKU category. It’s adjusting which fields appear on an RF scanner screen, chosen from the list the vendor shipped. It’s rate tables, put-away logic, exception thresholds, user permissions. None of this requires a developer, and a platform without it leaves you filing tickets for routine changes.
The analysis puts the limit plainly: you’re operating inside a sandbox the vendor built for you. The sandbox can be large and well-designed. It still has edges.
You find the edges the same way every time. A client asks for something specific, or a regulation shifts, or you bring in equipment nobody had in mind when the software was designed. The requirement needs a process flow, an API connection or a data object the vendor never anticipated. As the article puts it, configuration alone can’t solve that, and you’re back to the ticket and the change order.
What extensibility adds
Low-code and no-code tools put a visual layer over the underlying codebase. Instead of adjusting settings the vendor built, teams construct new capability, without writing backend code line by line. We’ve written before about why low-code flexibility is becoming a WMS requirement; the Logistics Viewpoints analysis sharpens the architectural case for it.
The examples in the article are concrete. Building a mobile returns-processing app that didn’t ship with the product. Mapping custom data fields that fire a webhook to a carrier system. Assembling automation flows for a fleet of autonomous mobile robots that arrived two years after go-live.
The architectural point underneath is the one worth holding onto. Those extensions live in an abstraction layer above the core application. They are not edits to the core.
Can you extend a WMS without traditional custom development?
In some platforms, yes. Low-code tools let operations and IT teams build screens, data fields and automation flows through visual builders rather than conventional backend development. How far that extends varies. Ask each vendor which changes their platform supports this way, and which still require professional services.
“Our operation is unique”: What that actually means during an evaluation
Some version of this comes up in most WMS evaluations, and it usually gets treated as a soft statement. It isn’t. Each of these sentences has a specific evaluation question inside it, and the answers separate platforms that look alike on a feature matrix.
“Every customer has different requirements.” The real question is whether client-specific workflows can be built without touching the core, and what happens to twelve of them when the platform updates. A 3PL adding four clients a year tends to run this test in production rather than in the demo.
“We don’t know what we’ll need three years from now.” Nobody does. That’s the argument for evaluating the mechanism rather than the feature list, because the feature list describes a platform’s answer to today’s requirements and says little about its answer to the ones you haven’t met yet.
“Every change to our current WMS requires customization.” This one describes a symptom worth tracing. It points to a platform where the configuration boundary sits close in, so ordinary operational change keeps crossing it. Worth asking what specifically got escalated last year, and whether the pattern would repeat on the platform being evaluated.
“We’re growing quickly.” Growth doesn’t only mean more volume. It often introduces more workflow variety: new service lines, new client verticals, new automation. Volume tests scalability. Workflow variety tests adaptability. Most operations need to evaluate both, and they are different questions.
How do you future-proof a WMS selection?
You cannot predict every requirement, so evaluate the mechanism instead of the feature list. Ask what happens when a requirement arrives that the platform was not designed for, who can build the change, how long it takes, and whether it survives the next platform update. Those answers stay useful longer than a feature comparison.
Why this surfaces during a cloud migration
Here is where the distinction stops being philosophical and starts costing money.
As vendors move customers off on-premises installations onto cloud SaaS, the analysis identifies legacy customizations as one of the larger obstacles, because they don’t transfer cleanly. Code written into a core application five years ago has to be understood, rebuilt or abandoned before the migration completes. Teams discover mid-project that a workflow they depend on daily was a custom build nobody documented.
Extensions that live in an abstraction layer behave differently. Custom business logic sits above the core application, so customer-specific extensions can be more isolated from changes to the core, reducing the upgrade conflicts associated with traditional custom code. They are not immune. Extensions can still carry dependencies on APIs, schemas, underlying services and compatibility rules, so the question to ask a vendor is how those dependencies are managed, not whether they exist.
There’s a second effect the article points to that matters for lean IT teams. When application building moves into a visual layer, the people who can make changes expand beyond developers to operations managers, industrial engineers and systems analysts. That doesn’t eliminate IT involvement. It changes what lands in your queue, and it raises a governance question covered further down.
What that looks like at scale is documented in the Watco case study. The rail and freight 3PL ran its terminals on different applications, pulling information together from manual spreadsheets. Justin Marr, Vice President of Business Solutions, described the starting point:
“All of our facilities, 65-plus, are on one common application, and that was not the case before. Some terminals used one application, other terminals used a different application. So it was very difficult to look at things holistically from an enterprise-wide perspective.”
Justin Marr, Vice President of Business Solutions, Watco
Per the published case study, Watco transitioned 52 terminal facilities across the U.S. to Footprint WMS within 12 months, standardizing data entry while maintaining the ability to customize workflows as needed. The operational benefits Watco lists include low-code customization of screens and fast deployment of new designs to production. These are customer-reported results published by Datex, not independently audited.
What happens to WMS customizations during a cloud migration?
Legacy customizations often do not transfer cleanly. The Logistics Viewpoints analysis describes them as one of the larger obstacles when vendors move customers from on-premises installations to cloud SaaS. Extensions built in a low-code abstraction layer sit above the core, so they can be more isolated from core changes and produce fewer upgrade conflicts.
The questions to ask every vendor
Most serious WMS vendors can meet an impressive list of requirements today. These questions are about what happens after that list changes. Bring them to every demo, and ask each vendor to answer on your workflows rather than their demo environment.
- What happens when you need a workflow the WMS vendor hasn’t already built?
- Can you create new functionality, or only configure existing functionality?
- Which changes require vendor professional services?
- Can you build customer-specific workflows without modifying the core?
- What happens to extensions when the WMS is upgraded?
- How easily can you connect new automation, systems or data sources?
- Who can make these changes: the vendor’s developers, your IT team, or your operational users?
- What governance controls exist around low-code extensions: permissions, test environments, versioning, approval, rollback and audit trail?
Two of those deserve a note.
On professional services, the objective isn’t zero. Complex integrations, architecture changes and high-risk workflows are reasonable places for vendor involvement. What matters is whether the vendor can draw the line clearly: what you can change yourself, what needs your IT team, and what needs them.
On governance, the mature version of the low-code argument isn’t that everyone can change the WMS. It’s that low-code can expand who is capable of adapting the system, while governance determines who is allowed to change what. If you run a regulated operation, that second half carries as much weight as the first. Ask about role-based permissions, separate test environments, approval steps, versioning, rollback and the audit trail before you ask how fast someone can build a screen.
One addition worth making: ask to see a workflow the vendor’s product did not ship with, built using their low-code tools rather than traditional custom development. Then ask how long it took and what happened to it at the next release.
These questions, plus a few more, are on a WMS Extensibility Evaluation Sheet you can bring to vendor demos and score side by side. It includes what to listen for on each question, what to probe further, and a scoring grid for up to three platforms.
Where the market is heading
The Logistics Viewpoints analysis argues that competitive position in this category is shifting toward platform extensibility. As core WMS capabilities mature, extensibility is becoming a more important dimension of differentiation, and the article’s view is that the vendors holding share will be the ones that let warehouse operators adapt their systems as requirements change, without giving up the benefits of a modern cloud platform.
The practical driver is that few warehouses run inside a single software environment any more. A facility may operate a core WMS alongside autonomous mobile robots, automated storage and retrieval systems, and IoT sensor networks. The article describes low-code tooling as the connective tissue between them, providing visual integration environments so operators can orchestrate work across systems without building extensive middleware.
The article publishes a vendor comparison, drawn from ARC’s Market Map, listing enterprise and mid-tier WMS suppliers offering low-code and no-code platforms:
| Vendor | Platform / Tool | Type of Low-Code Capability |
|---|---|---|
| Datex | Datex Studio | Core WMS built directly on a native LCAP |
| Manhattan Associates | Manhattan Active Architecture | Microservice extensions and UI modifications |
| Blue Yonder | Luminate Platform | Workflow automation and API/data extensions |
| Softeon | Composable Engine | Modular workflow orchestration and WES rules |
| SAP | SAP Build / BTP | Drag-and-drop apps connected to SAP EWM |
| Locus Robotics | LocusONE | Visual endpoint mapping and robotics flows |
Source: vendor comparison published in “The End of Rigid WMS Deployments: Configuration vs. Low-Code,” Logistics Viewpoints, August 10, 2026, highlighting insights from ARC Advisory Group’s Warehouse Management Systems Market Map.
The third column is where the distinction sits, and the entries do not describe the same kind of capability. Most are characterized as extension studios, platforms or frameworks. One is characterized as the core itself.
When some operations shortlist Datex
In the vendor comparison published in the Logistics Viewpoints article highlighting ARC’s Market Map, Datex is characterized as “Core WMS built directly on a native LCAP.” The distinction it draws is architectural: whether low-code is something added to the WMS or something the WMS is built on.
It’s worth being precise about what that means in the product, because a low-code layer that only reached the interface would not support the claim. Footprint WMS configuration governs the standard system: parameters, entities, statuses, order classes. Datex Studio is where teams build on top of it, and what Studio produces is configuration rather than compiled code.
That covers more than the interface. Backend and frontend flows carry business logic. Datasources query data, including OData against entity sets. Storage configs, entity extensions and user-defined fields extend the data model. Endpoints expose APIs. Report and document templates handle output, down to customer-specific shipping labels. Hubs, grids, editors and mobile configurations make up the screens.
The boundary matters too, and it is where evaluations usually go wrong. Vendor services remain the route for custom compiled code, middleware, changes to the core engine, the architecture of a large integration, and new core entities that need bespoke backend behavior. That is a narrower boundary than every unusual requirement becoming a ticket. It is not the absence of a boundary.
The pattern shows up in what customers were replacing. Crane Worldwide Logistics, a global 3PL with more than 130 locations across 30 countries, ran a previous WMS whose architecture used individual environments for each customer account. In Datex’s published account, that made adding new customers problematic and cost-prohibitive to implement. Kevin McKay, Product Manager, put the requirement plainly:
“3PLs are not a one-size-fits-all type of business. Having the ability to quickly make changes to meet customer requirements helps our operations run much more efficiently. Before Datex, this was a problem we were always trying to solve.”
Kevin McKay, Product Manager, Crane Worldwide Logistics
Billing configuration sits in Footprint. Castellini, a Cincinnati cold-chain 3PL running seven temperature zones across a 200,000 square foot facility, is the published example. Footprint WMS captures accessorial charges for value-added services, splits costs between entities, and supports multi-tiered volume billing rate structures. President and CEO Chris Larson described the requirement as needing “a system that had dynamic pricing components to make sure that we were fully recovering the revenue for those activities.” These outcomes are customer-reported.
The operations that tend to weigh this dimension heavily share a profile. Multi-client 3PLs whose client roster changes faster than a release cycle. Regulated warehousing where workflows carry documentation requirements that shift with the rules. Cold chain and food operations managing customer-specific handling. Companies adding automation that has to talk to the WMS. In each case the common factor isn’t complexity today, it’s the rate at which requirements change.
This dimension may matter less to you than it does to them. If your workflows are standardized and stable, if you ship DTC ecommerce through one channel, if lowest initial cost is the deciding factor, or if what you actually need first is an OMS rather than a WMS, extensibility is not where your evaluation should spend its energy. Configuration depth and implementation speed probably matter more, and several platforms are built around exactly that.
Evaluate the mechanism, not the moment
WMS evaluations tend to be a contest over the present tense. Vendors demonstrate what their platforms do, buyers score it, and the platform with the most complete answer to this year’s requirements list is the one that gets selected. That process is thorough and it measures the wrong thing, because the requirements list has a shelf life and the architecture doesn’t.
The sequence that holds up: define the workflows you already know are non-standard, ask each vendor to build one rather than describe it, find out who inside your organization would be able to build the next one, confirm how that change is governed and tested, and what happens to it at the next release. Don’t just evaluate what your WMS can do today. Evaluate how it will adapt to what your business needs next.
If you want to pressure-test how this works on your operation:
- Get a Preview: See how workflow configuration runs in Footprint WMS, and where Datex Studio fits. Bring the workflow your current platform can’t accommodate.
- Footprint WMS: Review the platform architecture and capability set before you finalize your requirements list.
- Talk to the Team: Bring your client mix, your integration map, your automation roadmap, and the change that’s currently sitting in a vendor queue.
