Why Every OMS Go-Live Reads Like a War Story

Kelly Goetsch headshot
image depicting a man with a military helmet in front of a computer screen, symbolizing the OMS war stories from implementation

Open LinkedIn on any given week and the same post appears under a different logo. A retailer or brand has just gone live on a new order management system, and the executive sponsor is taking a richly deserved victory lap. The format is so consistent at this point it could be a template.

“Yesterday, we went live with our new OMS. Anyone who went through a transformation like this knows what that means. Months of late nights, hard trade-offs, weekends sacrificed, and a thousand small decisions that no one outside the room will ever see.”

The next paragraph is almost always about the people.

“Programs like this are about the people. The product managers who held the line on what mattered. The engineers who worked hard to implement all the required features and connections to the systems. The operations and warehouse teams who had to learn new tools while still running the business. The partners who showed up when it counted.”

And the kicker is almost always some version of this.

“Thank you to the fantastic team for the hard work you put into bringing this project to life. So proud of what we have achieved.”

The posts are heartfelt and the work behind them is real. Replacing core commerce infrastructure at a brand that ships hundreds of thousands of orders a year is a genuinely difficult undertaking, and the people who pulled it off earned every word of recognition they receive. The question worth asking is not whether they deserve the applause, but why these projects almost always look like a 12-to-24 month death march in the first place, and whether they need to.

The Real Reason OMS Projects Take So Long

The OMS code itself is rarely the long pole. Order routing logic, inventory rules, allocation engines, sourcing optimization and exception handling are well-understood problems that the established vendors have been solving for two decades. The hardest problem in order management has never been the order management logic. It has always been connectivity.

By Forrester’s own framing, every OMS, regardless of how modern its architecture, requires connections to the systems around it: commerce platforms, ERPs, WMSes, 3PLs, marketplaces, payment processors, and shipping carriers. When a brand spends 18 months on an OMS implementation, the vast majority of those 18 months is spent building, testing, and stabilizing those connections. It is not spent on the OMS itself.

This is true regardless of whether the OMS in question is a Second Era monolith like IBM Sterling or Manhattan Associates, or a Third Era cloud-native platform like Fluent Commerce or Kibo. The architectural label on the box changes from release to release. The integration tax stays exactly the same.

That tax has only gotten heavier, because the systems an OMS now has to talk to have multiplied in three directions at the same time.

More selling channels

A decade ago, “omnichannel” meant a brand had a .com, a wholesale channel, and maybe an Amazon Seller Central account. Today the channel inventory looks fundamentally different. TikTok Shop, Instagram, Walmart Marketplace, Target Plus, eBay, and a long tail of vertical-specific marketplaces all have to be supported, because that is where consumers are spending their attention and their dollars. Each one has its own API quirks, its own onboarding requirements, its own data formats, and its own SLAs. eMarketer projects that AI platforms including ChatGPT, Google Gemini and Microsoft Copilot will account for $20.9 billion in retail spending in 2026, which means brands also have to be prepared for AI agents to become a transactional channel of their own.

More back-office systems of record

The ERP used to be the unambiguous system of record for order, financial and inventory data. That is no longer the case for the average mid-market or enterprise brand. NetSuite, SAP S/4HANA, Microsoft Dynamics 365, and Acumatica still anchor finance, but they are now sitting alongside data warehouses like Snowflake and Databricks, customer data platforms, planning systems, returns platforms, subscription engines, tax engines and a long list of best-of-breed specialty applications. Each one needs an authoritative view of order data, and each one needs that view in close to real time.

More fulfillment channels

Amazon set the consumer expectation for same-day and next-day delivery, and the rest of the industry has been racing to match it ever since. Meeting that expectation operationally means brands are no longer fulfilling out of two or three central warehouses. They are fulfilling from a national 3PL footprint, from regional micro-fulfillment partners, from drop-shippers, from physical retail stores acting as ship-from-store nodes, and from same-day delivery providers like DoorDash and Uber Direct. Each new fulfillment node is another endpoint the OMS has to know about, route to, and reconcile inventory with.

When data lives across that many systems, connectivity stops being an implementation detail and becomes the central problem to solve. That is the shift the OMS market is still adjusting to, and it is why the LinkedIn go-live posts continue to read like war stories.

Why Traditional Integration Approaches Make It Worse

Brands and their systems integrators have historically tackled the integration problem in one of two ways, and both of them get progressively more expensive as the number of endpoints grows.

The first approach is to fork an off-the-shelf integration template and run it on an iPaaS like MuleSoft, Boomi or Workato. The starting point is fast, because there is a template to begin from. The problem is what happens immediately after. The brand now owns that integration forever. Every Shopify API change, every NetSuite schema update, every new TikTok Shop endpoint behavior becomes the brand’s responsibility to detect, patch, and regression-test. The iPaaS license is the cheap part. The team required to keep dozens of forked integrations running is the expensive part, and that cost compounds every year.

The second approach is to build the connections point to point. This works for the first few endpoints and then collapses under its own weight, for the same reason any point-to-point network does. Metcalfe’s law cuts in both directions. The value of a network grows with the square of the number of connected nodes, and so does the maintenance burden when each connection is built and operated independently. A brand with 20 endpoints is not really maintaining 20 integrations, it is implicitly maintaining something closer to 190 pairwise relationships once those systems need to share data with each other through the OMS.

Underneath both approaches is a third problem that gets less attention than it deserves, which is the overhead of establishing a formal commercial relationship with every endpoint. Connecting to Walmart, Shopify, Amazon, NetSuite or a major 3PL is not a question of pointing at a public API and reading the docs. It involves joining a partner program, negotiating data processing agreements, passing initial certifications, complying with ongoing audits, maintaining minimum support standards, and in many cases meeting commercial thresholds before access is even granted. The integration engineering is real, and the partnership engineering is often a bigger drag on the timeline than the integration engineering itself. Brands that have never run that process before tend to underestimate it by an order of magnitude.

Multiply those three problems across the multiplying channel, back-office and fulfillment surface area, and the 18-month implementation timeline starts to look less like a failure of project management and more like a structural inevitability for any OMS that was not built connectivity-first.

What Connectivity-First Actually Means

Pipe17 was built around the observation that this problem is not getting better on its own and that solving it required a categorically different approach. Rather than treating connectivity as something brands plug into the OMS after the fact, Pipe17 treats the network of connections as the foundation of the platform, with order operations and AI built on top of it.

In practice, this means three things change for the brand.

The first is that the integration code is not the brand’s to build or own. Pipe17 maintains the connectors to Shopify, Amazon, Walmart, TikTok Shop, NetSuite, SAP, Microsoft Dynamics, the major 3PLs, the major WMSes and the major shipping carriers as a managed network. When TikTok Shop changes its API, that connector gets updated centrally. The brand does not get paged at 2am, and the brand’s engineering team does not get pulled off product work to write a patch.

The second is that the formal partnership work is also not the brand’s to do. Pipe17 has already done the work of joining the partner programs, signing the DPAs, completing the certifications, and standing up the ongoing compliance posture required to operate at the volume these endpoints expect. For the brand, what used to be a quarter-long procurement and legal exercise per endpoint collapses into plugging API keys into a network that already has the commercial and operational relationships in place.

The third is that the orchestration layer sitting above the network gets the benefit of clean, real-time, normalized data flowing through it from day one. Pipe17’s AI-native orchestration layer can route, allocate, promise, and orchestrate against that data without first having to spend nine months waiting for the integration project to stabilize. The Pipe17 MCP server and the Order Network eXchange (onX) protocol then expose those operations to AI agents and partner systems through standardized interfaces, which matters as agentic commerce moves from pilot to production over the next 18 months.

That combination is the reason Pipe17 customers go live in weeks rather than quarters. Aterian, operating across more than 40 channels, went live in under 90 days and now takes roughly $4 million a year out of its operating budget that previously went to integration maintenance and operational headcount. MaryRuth Organics replaced more than 20 manual order management steps with full automation without ripping out the systems around it. Those are not the kinds of timelines that produce 700-word LinkedIn victory laps about sacrificed weekends, because there were no sacrificed weekends to begin with.

The Shape of the Next Wave of OMS Projects

The LinkedIn go-live post is not going to disappear overnight. Brands still mid-implementation on Second Era or Third Era OMS platforms will continue to write them for the next several years, and the teams behind those projects will continue to deserve the recognition. The work is real and the wins are earned.

For brands that are still at the front end of an OMS decision, however, the calculus has changed. The question that determines outcomes is no longer which platform has the most configurable allocation logic or the most elaborate routing rules engine. In a maturing market, those features are table stakes. The questions that actually determine the shape of an OMS project today are these. What does the platform do about connectivity. Who owns the integrations after go-live. Who owns the partner relationships with Shopify, Amazon, Walmart, NetSuite and the major 3PLs. And how quickly can the back-office be brought into alignment with a front-end that Shopify has already made trivially fast to stand up.

When connectivity is built in from day one, the OMS implementation stops being the long pole. The LinkedIn post that follows it can be a routine release note instead of a war story.

Share this article:

Kelly Goetsch headshot
Table of Contents

More Posts

Replace Legacy Complexity 
With Modern SIMPLICITY

See how enterprise brands cut costs, speed implementation, and eliminate developer dependency with Pipe17.