The request sounds reasonable when it lands on your desk. Leadership wants to roll out ship-from-store across 50 locations. The strategy makes sense: margin compression on parcel shipping is real, customers expect faster delivery, and there is inventory sitting in stores that could be filling online orders instead of waiting for a floor sale.
So you go to your OMS vendor. Manhattan, Sterling, or whatever heavily customized platform your team has been running for the last decade. You ask what it takes to add store fulfillment. The answer comes back: a 4 to 6 month systems integration project. New middleware. Custom routing logic. A separate inventory feed. A change order for every store you add after the first wave.
If this sounds familiar, you are not alone. And the SI quote is not the real cost. The real cost is what happens after.
What Legacy OMS Platforms Were Actually Built For
The architecture of most legacy order management systems was defined in an era when fulfillment meant one thing: a warehouse receives an order, picks it, packs it, ships it. The entire data model, the routing logic, the inventory management, and the integration layer were designed around a single fulfillment node processing orders in batch.
This architecture worked well for its intended purpose. Warehouses are controlled environments. Inventory is received at a dock, scanned, put away in a known location, and cycle-counted on a regular schedule. The WMS knows where everything is. Orders arrive in batches, get processed in waves, and ship on a predictable cadence.
Store fulfillment is architecturally different in every dimension that matters.
A retail store is not a warehouse. There is no dedicated receiving dock with barcode scanning at every movement. Returns go back on shelves in inconsistent locations. Customers pick up items and put them back somewhere else. Inventory accuracy in a retail store averages 60 to 65%, compared to 95%+ in a well-run warehouse. The inventory data that was reliable enough to route orders in a warehouse context is not reliable enough to route orders in a store context.
A store associate is not a warehouse picker. They are helping customers, running the register, restocking shelves, and now being asked to fulfill online orders in between. They do not have a warehouse RF gun. In most legacy OMS implementations, they are working from a paper pick list or a desktop terminal in the back office. Every minute they spend hunting for an item that the system says is in stock but is not on the shelf is a minute they are not serving the customer standing in front of them.
And the network is not a single node. Ship-from-store means routing decisions across 10, 50, 100, or 1,000+ locations, each with its own inventory position, its own operating hours, its own capacity constraints, and its own fulfillment SLA. Legacy OMS platforms that were built to route orders to one or two warehouses do not have the architectural foundation to make intelligent routing decisions across a distributed store network.
The Real Cost Breakdown
The SI fee is the number that shows up on the proposal. It is not the number that shows up on the P&L over time.
The initial project. For a legacy OMS like IBM Sterling, adding store fulfillment is not a configuration change. It is a platform extension project. One enterprise brand received an implementation quote of $3.8 to $4 million with a timeline of 12 to 18 months. That is not an outlier. It is representative of what it costs to make a system do something it was not designed to do.
The integration maintenance. Every connection between the legacy OMS and the store network requires custom middleware. Every time a store opens, closes, or changes its operating hours, that middleware needs to be updated. Every time the business wants to change a routing rule (prioritize proximity over inventory depth, add a cutoff time, enable split fulfillment from stores), it is a change request, not a settings toggle. These change requests accumulate into a permanent SI relationship that costs six figures annually.
The routing rigidity. Legacy routing logic treats stores as secondary overflow nodes, not as first-class fulfillment locations. The rules are static: route to the warehouse first, fall back to stores if the warehouse is out of stock. There is no real-time evaluation of proximity, inventory depth, shipping cost, or store capacity. The result is routing decisions that are technically functional but operationally suboptimal, sending orders to the wrong store or to the warehouse when a closer store had the item in stock.
The inventory sync problem. Batch-based inventory sync, whether hourly or daily, creates race conditions in a store fulfillment context. An order routes to a store based on an inventory snapshot that was accurate an hour ago. By the time the associate goes to pick, the item has been sold off the floor. The order gets cancelled. The customer, who chose ship-from-store for speed, gets a cancellation email instead of a tracking number. That is worse than a slower shipment from the warehouse. It is a broken promise.
The associate experience gap. Most legacy OMS implementations give store associates no purpose-built execution tool. No mobile pick interface. No wave optimization for batch picking when multiple orders are assigned to the same store. No guided fulfillment workflow that accounts for the reality that the associate is multitasking between customers and online orders. The result is slow SLA cycles, high error rates, and associates who view ship-from-store as a burden rather than a capability.
What Modern Store Fulfillment Infrastructure Looks Like
The architectural requirements for store fulfillment are distinct enough that retrofitting a legacy OMS is often more expensive than deploying a purpose-built solution alongside it.
Modern store fulfillment infrastructure has three components that legacy systems lack.
First, event-based inventory processing. Instead of syncing inventory on a schedule, every inventory movement (sale, return, transfer, adjustment) is processed as an event and reflected across all locations within minutes. This is the prerequisite for reliable order routing. If the inventory data feeding the routing engine is stale, the routing decisions are unreliable regardless of how sophisticated the routing logic is. Follett, operating 1,100+ stores with 1,000+ Shopify POS terminals and over 20 million SKUs across multiple inventory types (new, used, rental), runs on Pipe17 as the inventory source of truth across every location. Event-based processing at that scale is not theoretical. It is in production.
Second, intelligent routing that treats stores as first-class fulfillment nodes. This means routing logic that evaluates proximity, inventory depth, store capacity, operating hours, and SLA windows in real time for every order. It means location group routing: route to the nearest store in a group first, then to other locations in the network, then to dropship vendors. It means automatic rejection re-routing: when a store cannot fulfill an order (item not found, associate unavailable, SLA breach risk), the order re-routes to the next best option without manual intervention.
Third, a mobile execution layer for store associates. Wave-optimized pick routes that batch multiple orders into a single floor walk. Guided fulfillment workflows on a mobile device rather than a paper list or a desktop terminal. Carrier rate management and label printing at the store level. This is what turns a store associate from someone who interrupts their real job to hunt for products into someone who fulfills online orders as a natural part of their workflow.
Progressive Migration: You Do Not Have to Rip and Replace
The most common objection to modernizing store fulfillment is the perceived risk of replacing a legacy OMS that, despite its limitations, is running production order flow. That objection assumes a binary choice: keep the legacy system or replace it entirely.
Progressive migration eliminates that binary. The approach is straightforward: deploy the modern store fulfillment layer alongside the legacy OMS. The legacy system continues to handle what it handles well (warehouse fulfillment, existing channel integrations, financial data flow to the ERP). The new layer handles what the legacy system cannot: store fulfillment routing, real-time inventory across retail locations, and associate execution tools.
This is not a theoretical pattern. One enterprise brand moved from an $8.5 million per year legacy stack to Shopify and Pipe17 and reduced their annual operating cost by nearly half. They did not do it in a single cutover. They started with the use case their legacy OMS could not handle, proved value, and expanded.
Follett followed the same pattern: running Pipe17 alongside their legacy systems, going live store by store, using Pipe17 as the inventory source of truth across the full network while the legacy system continued to handle the workflows it was already running.
Every integration built in the first phase carries forward. There is no throwaway work. The store fulfillment layer becomes the foundation for broader order operations modernization, deployed at a fraction of the cost and timeline of a legacy OMS extension.
Pipe17 enterprise store fulfillment onboarding runs approximately $200,000 over 3 to 4 months. Compare that to the $3.8 to $4 million and 12 to 18 months that a legacy OMS extension requires. The cost difference is not incremental. It is an order of magnitude.
The Cost That Compounds
Adding store fulfillment to a legacy OMS is not a one-time expense. It is a recurring cost that compounds every time the business changes. Every new store added is a configuration project. Every routing rule change is a change order. Every inventory sync improvement requires middleware modification. Every new channel that needs to interact with the store network is an integration project.
The brands that are scaling store fulfillment successfully are not the ones that found a way to make their legacy OMS do something it was never built to do. They are the ones that recognized the architectural mismatch and deployed a purpose-built layer alongside it.
The question is not whether your legacy OMS can support store fulfillment. With enough SI budget and enough time, almost anything can be made to work. The question is whether that is the best use of $4 million and 18 months when the alternative costs a fraction of that and goes live in a quarter.
See how Pipe17 StoreOps turns your retail stores into first-class fulfillment nodes. Or talk to our team about a capabilities assessment for your store network.
