Article by JJ Karambelas
In retail, investment decisions around core systems are rarely simple. With pressure to improve customer experience, reduce costs, and increase agility, many retailers are asking the same question:
Should we replatform our ERP, or prioritize a Distributed Order Management (DOM) system?
For most retailers, it is more reasonable to invest in a distributed order management system. Although replatforming the ERP might enhance finance and supply chain processes, it won’t have much of an effect on fulfillment flexibility, inventory visibility, or conversion rates.
A DOM addresses these areas directly and can generally be implemented within months rather than years. It also separates order orchestration from the ERP, which in turn makes a future replatforming easier and less risky.
It is a key decision, as both options promise operational improvements, but the commercial and technical results differ significantly.
The Case for and Against ERP Replatforming
Most retailers have plenty of reasons to replace an aging ERP. Years of customization can make the system difficult to maintain, leaving finance and supply chain teams stuck with slow or inefficient processes. A new ERP can address these problems and give the wider business a more consistent foundation.
The drawback is that most of these benefits are internal. Replatforming will not necessarily improve inventory accuracy for customers, offer more fulfillment options, or increase conversion. So, although the ERP may be the most obvious system to replace, it may not be the one that delivers the most immediate commercial value.
Potential benefits of ERP replatforming
A replatform modernizes core finance and supply chain processes, and where legacy versions have been heavily customized, it can remove a significant amount of technical debt. It also offers long-term standardization across the business, which matters more as the number of markets and entities grows.
Limitations and risks
ERP replatforms are expensive, multi-year projects that frequently exceed budget, and Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, with as many as 25% failing catastrophically.
The impact on the customer is limited. ERPs are not built for real-time inventory orchestration, flexible fulfillment, or omnichannel scenarios, and even modern versions are slow to deploy new fulfillment options such as ship-from-store, marketplaces, or endless aisle. Retailers frequently end up rebuilding the same middleware that the replatform was meant to remove, to compensate for what the ERP cannot do.
Why ERPs struggle with fulfillment
ERP inventory is designed for financial reconciliation rather than real-time availability. Stock positions are accurate at period close rather than at the moment a customer adds to their basket, and the record is a netted quantity rather than what is available where, reserved against what, and reachable within a promised delivery timeframe.
Order logic is transactional rather than rules-based, so an ERP records when an order is placed and fulfilled. It is unable to evaluate which locations should fulfill an order based on margin, distance, capacity, markdown risk, and carrier cut-off. Essentially, every new fulfillment scenario becomes a customization rather than a configuration change.
A retailer who decides to replatform in order to modernize, may then discover that the ERP still cannot provide a predicted delivery date across a distributed network, and so commission a bespoke availability layer within eighteen months. The middleware that the replatform was supposed to eliminate returns, built by a different team, on a shorter timeframe, with a smaller budget.
What about the order management module in your ERP or ecommerce platform?
Most ERP and ecommerce platforms include order management functionality. These handle sequential fulfillment from a small number of nodes and single-source allocation. This means they are not suitable for real-time sourcing across stores, warehouses, and drop-ship partners, for split shipments, or for fulfillment rules that vary by seasonality and promotions.
The test is not the number of locations, but the nature of the decision. If every order has one obvious source, a native module is usually enough. Once sourcing requires weighing stock against cost, capacity, delivery promise, and markdown risk across several locations, the native module becomes a constraint, because it was built to record the decision rather than to make it.
Distributed Order Management: A More Direct Path to Customer Value
Distributed Order Management (DOM) sits between front-end channels such as ecommerce, POS, and marketplaces and the ERP, deciding which of your locations fulfills each order. It is the layer that makes omnichannel order management possible without hard-coding fulfillment rules into the ERP or the ecommerce platform.
Key benefits of DOM
A DOM unifies stock from warehouses, stores, and drop-ship partners into a single real-time view, making ship-from-store, click-and-collect, endless aisle, and split shipments possible with minimal disruption to the ERP.
The commercial effect follows from that. Accurate availability prevents stock-outs and reduces cancellations, which lifts conversion, while routing each order to the most profitable location lowers logistics and markdown costs.
It also deploys incrementally, delivering benefits within months rather than years, and acts as a layer of agility beneath the channels, so ERP, ecommerce, or WMS can be changed later without disrupting fulfillment logic.
Challenges of Distributed Order Management adoption
A DOM needs clean integration with ERP, WMS, POS, and digital sales channels, which takes time when those systems are legacy or fragmented. It is also only as good as the data it receives, so poor stock accuracy or delayed updates from upstream systems will limit what it can do.
There is a process cost in addition to the technical one. Store teams and fulfillment operations have to adapt to new workflows, whether that is ship-from-store picking or revised allocation priorities. And while a DOM is considerably cheaper than an ERP replatform, it still requires real investment in both technology and change.
Partner selection matters as much as software selection. Look for a DOM vendor and an implementation partner with proven experience of decoupling order flows from specific ERP platforms, since that is where most of the risk sits.
There are some challenges to bear in mind, but they are typically short-term hurdles, whereas the benefits compound quickly.
How ERP and DOM Compare Commercially
| ERP Replatform | Distributed Order Management | |
| Cost | High (multi-year, multi-million) | Moderate, modular implementation |
| Time to Value | 18–36 months | 4–9 months |
| Customer Impact | Low (back-office efficiency) | High (CX, fulfillment flexibility, conversion) |
| Agility | Limited, hard-coded processes | High, configurable fulfillment rules |
| Risk | High (disruption, scope creep) | Lower (layered approach, incremental rollout) |
| Dependency | Often locks you into vendor roadmap | Future-proofs ERP, WMS, and ecommerce choices |
Should you Ever Replatform ERP First?
There are scenarios where prioritizing an ERP replatform is unavoidable. The clearest are when the ERP is out of support and presents a security or compliance risk, or when the finance and supply chain modules are so outdated that they actively constrain the business.
The commercial case for DOM first
A DOM delivers measurable top-line value within the same fiscal year through higher conversion, fewer cancellations and more orders captured. ERP replatforms typically take years to show a return, if they show one at all. Those early wins in fulfillment and customer experience can then fund or justify the later ERP transformation.
The technical case for DOM first
A DOM decouples order orchestration and inventory availability from the ERP, reducing dependence on ERP customization. It can be rolled out incrementally, starting with ecommerce and extending to stores, marketplaces and wholesale. Once it is live, the ERP beneath it can be upgraded or replaced with far less disruption.
What stays in place when the ERP changes is the part the customer sees. The availability calculation, the sourcing rules, the delivery promise logic, and the APIs that the channels call all sit in the DOM, so the storefront asks the same system the same question before and after the migration.
The ERP’s role narrows to supplying stock movements and financial records through defined interfaces. Replacing it means repointing those interfaces rather than rebuilding the fulfillment logic, because the logic was never in the ERP to begin with.
Running ERP and DOM in parallel
Retailers can stabilize or modernize finance and supply chain through an ERP replatform while deploying a DOM to address customer-facing priorities.
The layered approach protects business continuity by shielding front-end channels from ERP changes and preventing disruption to fulfillment logic during migration. It also lowers risk in both directions: ERP delays do not block customer-facing innovation, and the DOM provides a safety net for fulfillment even if ERP milestones slip.
Running the two in parallel does depend on getting the architecture right, since the shielding only works if the interfaces between them are properly defined from the start.
Does this apply to you?
Prioritize DOM if three or more of the following apply to your business:
- You have more than one physical location or plan to within eighteen months.
- Online orders are canceled or short-shipped because the stock shown as available was not available.
- Adding a fulfillment option, such as click-and-collect or marketplace, takes more than one quarter.
- Store stock cannot be seen by the ecommerce channel, or is visible but unsellable.
- Fulfillment routing rules are hard-coded, meaning that changing them requires developer resources.
Make ERP your focus if your current version is no longer supported or if the finance and supply chain modules are actively hindering reporting, compliance, or growth. Even then, you should deploy DOM alongside rather than after.
Lead with DOM not ERP
Retailers do not earn customer loyalty through better financial systems; rather, they achieve it by offering reliable, flexible fulfillment, ensuring a consistent experience across all channels, and fulfilling their promise to customers clearly and predictably. It is DOM that makes this possible.
By deploying a Distributed Order Management system first, retailers unlock immediate commercial impact – higher conversion, reduced fulfillment costs, and greater customer satisfaction.
At the same time, it aims to reduce the risks of any future ERP replatforming by separating the service promise from back-office processes. The DOM is that layer, built to absorb changes in customer-facing requirements without those changes reaching the systems beneath it.
To sum up, if you have to decide where to make your first investment, DOM offers greater value faster and with less risk. Moreover, if it is necessary to carry out both transformations in parallel, DOM makes sure that your customer experience remains protected and profitable.
FAQs
Can retailers add DOM to their existing technology stack without replatforming the ERP first?
Yes. There is no need to replace the ERP before adding a DOM. The ERP can continue handling its existing work, while the DOM uses order and inventory data to decide how each order should be fulfilled.
It will need to integrate properly with the ERP, WMS, POS, and sales channels, but the ERP’s age is not the deciding factor. Putting the DOM in place first can also make a later ERP replatform less disruptive, as the fulfillment logic has already been separated.
What should retailers look for when evaluating ERP and DOM vendors for their next technology investment?
When evaluating DOM vendors, retailers should determine how fulfillment rules are set and whether their own teams can change them without relying on the vendor. It is also worth asking for examples of previous projects where order flows have been separated from an ERP, along with a realistic view of what can be delivered in the first few weeks.
ERP vendors should make it clear to people how their systems determine the level of inventory available in stores, warehouses, and other stock locations. Retailers must also find out whether this feature is provided as standard, can be configured, or requires custom development. Regardless of the platform under consideration, the integration partner’s experience is just as important as the software itself.
Can an ERP handle distributed order management?
An ERP can support basic order management, but it will often struggle when orders need to be sourced across a large network of locations. Its inventory records are primarily designed for financial control, not for providing a live view of the stock available to customers. It can record an order, but it is not built to continually assess which location should fulfill it based on stock, cost, capacity, and service requirements.
Retailers often fill these gaps with custom integrations or middleware. This may work initially, but the cost and complexity tend to grow as more locations and fulfillment options are added. A DOM is designed specifically to manage these decisions.
Do you need a DOM if you only sell online?
Sometimes. The number of locations fulfilling orders matters more than the number of sales channels. An online retailer shipping everything from one warehouse is unlikely to need a DOM. If orders can be sent from several fulfillment centers, drop-ship suppliers, or third-party logistics providers, the business still needs to choose the right source for each one. That is where a DOM becomes useful, even without stores.
