You have been asked to roll out ship-from-store across fifty locations. The business case is clear: the inventory is already sitting in the stores, customers want faster delivery, and activating stores as fulfillment nodes is the obvious move. So you take it to your OMS vendor, and the answer comes back as a four-to-six-month systems integration project just to add fulfillment locations and the routing rules to go with them. Not a configuration change. Not a support ticket. A project, with a scope document, a statement of work, and an invoice to match.
If that sounds familiar, you are not doing anything wrong, and neither is your team. You are running into the fact that your order management system was never built for what you are now asking it to do. Adding store fulfillment to a legacy OMS does not extend its capabilities. It reveals its limits. And the cost of those limits does not stop at the first SI invoice. It compounds every time the business needs to change.
What Legacy OMS Platforms Were Actually Built For
The enterprise OMS platforms most large brands run, Manhattan, IBM Sterling, and heavily customized in-house systems, were designed for a different era of commerce and did that job well. They were built around a single fulfillment node, or a small number of distribution centers, processing orders in batch cycles, in a world that existed before ecommerce reshaped what fulfillment had to do. For routing warehouse orders through a stable network that rarely changed, that architecture was sound.
Store fulfillment breaks every one of those assumptions. Instead of one node or a few DCs, you have ten, a hundred, or a thousand stores, each one both a retail location and a fulfillment point, each with its own inventory that shifts by the hour as walk-in customers buy off the same shelves. Instead of a stable network, you have one that changes constantly as stores open, close, and move in and out of the fulfillment pool. Instead of a controlled warehouse with a receiving dock and cycle counts, you have a sales floor where inventory accuracy is structurally lower. A system built for the first world does not adapt to the second by configuration. It has to be rebuilt around it, one custom project at a time, which is exactly what the SI quote represents.
The Real Cost, Line by Line
The SI invoice is the visible cost. It is also the smallest part. Here is what store fulfillment on a legacy OMS actually costs, and why the total keeps growing.
There is the systems integration fee itself, and it is not small. When The Container Store looked at what a legacy build would take, the implementation quote came in at $3.8 to $4 million and twelve to eighteen months, and that is before the platform routes a single store order. But the more important point is that this cost recurs. Every routing rule change, every new store added to the network, every new channel that needs to feed store fulfillment, tends to route back through the same integration work. What looks like a one-time project is really a standing tax on change.
There is integration fragility. Store fulfillment on a legacy OMS usually means custom middleware stitching the storefront, the POS, the inventory systems, and the stores together. Both sides of every one of those connections has to be maintained as APIs and data models evolve, and the more custom the build, the more it breaks when anything upstream shifts.
There is routing rigidity. Legacy routing was built to send an order to a warehouse, not to weigh live inventory, proximity, capacity, store hours, and cut-off times across a network of stores and pick the best one, then reroute automatically when a store cannot fulfill. Bolting that logic on is custom work, and it is brittle.
There is the inventory problem, which is worse in a store than anywhere else. Legacy platforms sync inventory in batches, hourly or nightly, which means orders get routed to stores based on stock data that is already stale by the time an associate goes to pick. In a warehouse, that lag is survivable. On a sales floor, where inventory accuracy already runs lower because customers are pulling from the same shelves, batch sync turns into overselling and cancellations. We unpacked why this specific failure sinks ship-from-store programs in why 60% inventory accuracy isn’t enough.
And there is the associate experience gap, the one that rarely makes the business case but shows up every day in the store. Most legacy OMS systems have no associate-facing execution tool. The associate picks online orders from a printed list or a desktop terminal in the back, walking the floor from memory, with no guided routing and no mobile capture. That is slow, it is error-prone, and it is a big reason store fulfillment SLAs slip once volume climbs.
Add those together and the pattern is clear: the cost of store fulfillment on a legacy OMS is not a number you pay once. It is a rate you keep paying, and it rises with every change the business makes.
What Modern Store Fulfillment Infrastructure Looks Like
The alternative is not a bigger, faster legacy OMS. It is a different architecture, built for a distributed store network from the start, and it rests on three things.
The first is real-time, event-based inventory. Rather than reconciling stock on a schedule, a modern layer processes each inventory movement as an event and keeps one accurate picture across every store and channel within minutes. That single change removes the stale-data problem that causes store oversells, and it is the foundation everything else depends on, because routing is only as good as the inventory data feeding it.
The second is intelligent routing that treats stores as first-class fulfillment nodes. Not a single-store assignment, but network-level logic: route to the nearest store in a location group first, then to other stores in the group, then to a dropship vendor, weighing live inventory, capacity, store hours, and cut-off times, with automatic rejection re-routing when a store cannot fulfill. Stores are first-class citizens in the routing decision, not an exception bolted onto warehouse logic.
The third is a mobile execution layer for associates. Instead of a paper list, the associate gets a guided app that hands them wave-optimized pick routes and walks them through fulfillment step by step on a mobile device. This is the piece that keeps store fulfillment fast and accurate at volume, because it meets the reality that a store associate is not a warehouse picker and the store was not designed as a fulfillment center.
This is the infrastructure Pipe17 StoreOps provides, and the reason it can go in without replacing the systems around it is the subject of the last section.
You Don’t Have to Rip and Replace
The reason store fulfillment projects stall is that they get framed as OMS replacements, and no enterprise brand wants to run a multi-year, multi-million-dollar rip-and-replace to add one capability. The better path is progressive migration: put a modern layer alongside the legacy OMS, starting with the exact use case the legacy system cannot handle, which is store fulfillment.
The legacy OMS keeps doing what it already does. The modern layer takes on store fulfillment, proves its value in production, and then expands to more of the operation on your timeline. Every integration built in that first phase carries forward, so there is no throwaway work and no single high-risk cutover. Follett did exactly this, running Pipe17 alongside its legacy systems and going live store by store across more than 1,100 locations, with Pipe17 now the inventory source of truth across 20 million-plus SKUs and over 1,000 Shopify POS terminals. The Container Store is taking the same phased path for ship-from-store, mix-cart, and inventory centralization across its 103 stores rather than betting on one big replacement. (The mechanics of running alongside a legacy OMS are covered in how to replace a legacy OMS without a big-bang migration.)
The economics of the phased path are hard to argue with. Against the $3.8 to $4 million and twelve to eighteen months a legacy store-fulfillment build was quoted at, enterprise store fulfillment on Pipe17 comes in around $200,000 and three to four months. One reference brand moved off an $8.5 million-per-year legacy stack to Shopify plus Pipe17 and cut its annual cost by nearly half. Those are not just smaller numbers. They come from not rebuilding a single-node system to do a job it was never designed for.
The Takeaway
If your OMS vendor just quoted you a half-year project to add store fulfillment, that quote is telling you something true: the system was built for a single fulfillment node and a stable network, and store fulfillment is neither. You can keep paying to force it, one custom project at a time, and keep paying again with every change. Or you can add a layer built for a distributed store network alongside what you already run, start with store fulfillment as the proof, and expand from there.
See how Pipe17 StoreOps turns your retail stores into first-class fulfillment nodes. Explore StoreOps. Or talk to our team about a capabilities assessment.
