What happens when you replace your commerce platform but keep the old order management system
The replatform goes well. Checkout is faster, merchandising can make changes without filing a developer ticket, and the agency bill comes down. Six months later the operations team is still doing the same work, and it isn’t always obvious why.
The reason usually sits one layer below the storefront. You replaced the commerce platform and kept the order management system (OMS).
How a temporary compromise becomes permanent
Digital usually owns the storefront decision. IT or supply chain owns order management. Putting Shopify in front of the legacy system is the option neither side has to argue against, so it often wins. Within a year a temporary compromise is being treated as the architecture.
Keeping the legacy OMS through cutover can be sensible. Replacing the storefront and the order layer at the same time adds risk to a project that’s already vulnerable to scope creep. The problem is letting the temporary system become permanent, usually because nobody owns the decision to revisit it.
Why the business case starts to fall apart
The case for Shopify usually rests on lower costs, faster launches and fewer agency hours. If the OMS stays, the license line may change while operating costs don’t. The integration team remains, the middleware contract renews, and the change control board still meets every Thursday.
A simple exercise makes this visible. List every OMS customization, then identify the ones built around limits of the old platform: batch-only inventory, no storefront API, one fulfillment node, EDI-only partners, no real-time carrier rating. Much of the logic accumulated over ten years turns out to be a workaround for problems modern commerce has already solved.
Your slowest system still sets the pace
A new channel can go live on Shopify in days. The same work takes months in a legacy OMS, because each channel needs a new order type, new mappings and new allocation rules. At one specialty apparel retailer above $1 billion in revenue, a single social commerce integration with the legacy commerce platform took two to three months of engineering.
Marketing sees a fast front end while operations keeps saying no. That disagreement gets treated as a people problem when the constraint is the system behind the storefront.
Where the two systems clash
Shopify’s continuous event architecture and the batch processing of older systems are built on opposite assumptions. The mismatch shows up across several operational areas.
| Operational Area | Modern Commerce (Shopify) | Legacy OMS Constraint |
| Event handling | Continuous event streams and real-time APIs. | Batch windows, nightly jobs and file drops. |
| Inventory control | Real-time location availability for omnichannel selling. | Static safety buffers to prevent overselling, which lock up working capital. |
| Post-purchase | Customers expect self-serve address changes and size swaps. | Orders lock as soon as they reach the warehouse, so the fix is a manual cancel and reorder. |
| Data granularity | Native support for bundles, subscriptions, B2B and multi-currency. | Custom fields and fragile mapping documents that aggregate or drop the detail. |
Shopify’s own routing doesn’t close the gap. Multi-location stores get four rules, and standard plans can’t reorder them or add logic. Only Plus opens customization through Shopify Functions. Shipping cost, margin and customer tier aren’t inputs to the routing decision at all.
What customers experience
People expect to change an address or swap a size twenty minutes after checkout. In a legacy OMS the order locks as soon as it reaches the warehouse, so the only option is cancel and reorder. That creates a refund, another pick and a support ticket. Exchanges break the same way. A direct swap requires reserving replacement stock before the return arrives, and older systems generally can’t do it, so the customer gets a refund and the business gives up a sale a competitor would keep.
Uptime is the other exposure. At that apparel retailer the storefront and API layer run in the cloud while the OMS runs in a data center. When the data center goes down, and it does, sometimes because a utility crew cut a line, real-time inventory calls fail. Buy online pick up in store (BOPIS) disappears, ship-from-store eligibility checks stop working, and customers lose access to order history and returns. The modern front end inherits the old system’s availability.
Two smaller things from the same operation tell you as much as the outage. Ship-from-store eligibility rules sit hard-coded in configuration files, so one or two individuals can change them and the operations team that owns the decision can’t. And when reward certificates are applied at checkout, margin erodes enough that the third-party warehouse becomes the cheaper path, but the router can’t see it. They find the loss a day or two later.
How Shopify becomes the integration layer, and what gets lost
After go-live the CEO asks for a social commerce channel. Shopify has a native connector that takes a few clicks. The legacy OMS needs a project. The easiest path gets taken repeatedly, and eventually every order in the business passes through the commerce platform. Shopify is built to sell, and it’s very good at that. Acting as the system of record for orders created somewhere else is a different job.
Channel data loses detail as it moves through the stack. A marketplace order carries line-level promotions, settlement data and fee structures. The connector maps what fits the Shopify order object and leaves out the rest. Nothing downstream can recover what was never captured, so the gap arrives in the ERP as a permanent condition.
Settlement is where it bites. The marketplace pays you net of fees, promotions, adjustments and chargebacks. Reconciling that payout against revenue needs order-level detail matching what the marketplace recorded. Route everything through the storefront and finance is matching a payment against orders that no longer carry the detail the payment was calculated from.
There are catalog constraints too. Shopify has contractual rules about where product data can be pushed. If the catalog master lives in the ERP, funneling it through Shopify to reach channels gives you less freedom than going direct.
One personal care brand processed more than 75,000 orders a month through a social channel, but only umbrella orders reached its ERP. Without line-level detail they couldn’t analyze SKU performance or reconcile settlements, and the close was harder to defend to auditors. One employee spent more than ten hours a week rebuilding the missing detail in spreadsheets.
That’s the bill for using a storefront as a data layer. It doesn’t arrive in IT. It arrives in accounting, at month end, as a person with a spreadsheet.
Three paths forward
Once the operational pain becomes undeniable, most businesses are choosing between three options.
| Strategy Path | Implementation Risk | Operational Complexity | Speed to Value | Ideal Fit |
| Modern OMS replacement (Replace legacy monolith with cloud-native OMS) | High, concentrated at cutover | Low once complete | Medium, 6 to 12 months | Brands outgrowing basic routing with complex 3PL/ERP networks. |
| Dual OMS migration (Run modern order layer in front of incumbent) | Medium, phased | High while both run | Fast, iterative | Enterprise retailers with high volume across distinct channels. |
| Build around legacy OMS (Treat as bridge with decommission date) | Low at the start | High and compounding | Slow, bottlenecked | A bridge under 6 months ahead of a planned replacement. |
The second path is worth being honest about. Two systems hold a version of the order for a while, reconciliation gets harder before it gets easier, and somebody has to decide per data type which system wins and write it down where people can find it. There’s no version of this without headaches. The question is which ones you’re choosing and for how long. On day one the second and third paths look identical. The difference is a decommission date.
Results from a modern order layer
- A footwear brand with the engineering talent to build its own OMS calculated that maintaining integrations on both the warehouse side and the Shopify side would cost three times what working with a partner cost. Business users there now find and fix a problem in seven minutes without a ticket, and can bring a new warehouse online in three weeks.
- A consumer electronics brand cut its ecommerce operations team from four people to two and reduced click-to-delivery from 15 days to 7.
- A campus retailer running 1,100 stores replaced IBM Sterling and went live in three months.
Diagnostic: is your replatform actually finished?
Five questions to work out whether the legacy OMS is throttling the Shopify investment. If the answers trip the thresholds below, the transformation is half done.
1. What percentage of orders require manual work? Above 2% and the legacy mapping is failing and eating margin.
2. How long does adding a channel take, measured from the request rather than the build? More than 4 weeks of engineering and the order layer is an active brake on revenue.
3. How much working capital is locked in safety stock? Buffers above 5% of total inventory mean batch allocation is costing you sales and margin.
4. What can the current OMS do that a modern order layer can’t? If the answer rests on ten-year-old workarounds for limits that no longer exist, you’re maintaining debt rather than differentiation.
5. Who maintains the integration after the person who built it leaves? Institutional knowledge held by one or two employees is a continuity risk.
If the answers are weak, the replatform isn’t finished. The business paid for the half customers can see and left the operational constraint firmly in place.
