In a single stretch of 2026, three things happened to companies whose software sits inside a lot of ecommerce order stacks. A warehouse and fulfillment platform used by thousands of 3PLs and brands was acquired: Descartes bought Extensiv for about $120 million in cash. A global logistics provider disclosed a data breach that rippled across banks, retailers, and other downstream businesses. And a long-standing supply-chain software vendor announced a roughly 6% workforce reduction as it refocused investment.
Read the headlines separately and they look like three unrelated events. Read them as an operator and they land on the same place: the wiring between the systems that run your orders.
Every brand at scale runs on connections it does not control. Your storefront talks to your OMS. Your OMS talks to an ERP, a WMS, one or more 3PLs, a returns platform, a tax engine, a handful of marketplaces. Most of those connections were built once, by someone, to move a specific set of fields between two specific systems. They work quietly for months. Then one of the vendors on either end changes, and the connection becomes the most fragile thing in the operation.
The liability lives in the wiring
A point-to-point integration is a direct, custom link between two systems. Storefront to OMS. OMS to a single 3PL. Each link speaks the exact dialect of the two endpoints it was built for: their fields, their authentication, their quirks, their version.
That specificity is the whole problem. A point-to-point link has no independent existence. It is only as stable as the two systems it connects and the assumptions baked into it the day it was written. Add a fourth channel and a third warehouse and the number of these bespoke links grows faster than the systems themselves. Teams end up maintaining a web of connections that no single person fully understands, where a change on any endpoint can silently break order flow somewhere else.
For a while, nothing forces the issue. The web holds. Then a vendor changes hands, changes its API, or changes its priorities, and the bill for all that accumulated specificity comes due at once.
What vendor churn actually does to an order stack
Three kinds of change show up again and again, and each one hits point-to-point integrations in a predictable way.
Acquisition. When a platform is acquired, the roadmap you bought into is now someone else’s roadmap. The acquiring company reprices, re-tiers, or eventually consolidates the product into its own suite. APIs get deprecated on the acquirer’s schedule. In the Descartes and Extensiv case, the stated rationale was to combine warehouse and fulfillment data with an existing logistics portfolio so service providers can scale on a single technology provider. That is a reasonable strategy for the vendors. For a brand or 3PL with a custom integration into the acquired product, it means the ground under that integration is now moving on a timeline you do not set.
Breach or outage. When a logistics or software provider goes down or gets compromised, orders wired directly to it stop moving. A point-to-point link has no concept of a fallback. It knows one endpoint. If that endpoint is unreachable, the orders queue up or fail, and the exceptions land on your team during the exact window when the vendor is least able to help you. The CEVA breach showed how far the blast radius reaches once a single logistics node is disrupted: the effects were felt well beyond the company itself.
Restructuring. When a vendor cuts headcount or refocuses investment, the visible news is the layoff. The operational effect is slower support, longer fix times on the product areas that are no longer strategic, and a roadmap that quietly stops moving in the direction you were counting on. Public filings rarely name which products are affected, which is exactly why it is hard to plan around. You find out through response times and deprecation notices.
None of these are rare or exotic. They are the normal life cycle of a software and logistics market that is consolidating. The mistake most stacks make is treating each one as a surprise.
Most brands evaluate the wrong thing
When teams choose a 3PL, an OMS, or a marketplace connector, they evaluate features, price, and current reliability. Those matter. They also describe the vendor as it exists on the day you sign.
The question that predicts pain two years out is different: what happens to my order flow when this vendor changes? If the honest answer is “we rebuild the integration,” then every vendor in the stack is a scheduled outage waiting for its trigger. The stack is only as durable as its least stable relationship, and you have signed up to absorb every one of those changes by hand.
Designing for that reality means moving the connections off the endpoints and into a layer that exists to hold them.
An order operations layer holds the connections for you
An order operations layer sits between your systems of record and your channels and fulfillment partners. Instead of each system wiring directly to each other system, they all connect to the layer, and the layer connects out through managed connectors: pre-built, maintained integrations to platforms like Shopify, NetSuite, SAP, Amazon, and the major 3PLs.
The difference is ownership. The layer’s vendor maintains a managed connector centrally and keeps it current as platforms evolve. When an endpoint changes its API, the connector is updated in one place. When you add a channel or a warehouse, you configure a connector rather than commission a build. The layer also normalizes the data passing through it, so an order looks the same to your operation whether it came from your storefront, a marketplace, or an agent, and a fulfillment instruction looks the same whether it is going to one 3PL or another.
That normalization is what turns vendor churn from a rebuild into a swap. (For the mechanics of what a managed connector is and how it differs from a hand-built link, see the companion piece, What Is a Managed Connector?)
Run the three scenarios again through a layer like this:
When a platform you use is acquired and its API shifts, the connector absorbs the change centrally. Your order flow keeps its shape while the connector is updated once for everyone who uses it, rather than once by every team that built its own link.
When a provider suffers a breach or outage, routing lives in the layer, so orders can be rerouted to another fulfillment node while the affected one is down. The layer retries, holds, and reroutes on its own while the affected node recovers.
When a vendor restructures and its product stops moving, you are positioned to migrate on your own schedule. Because the layer already speaks to alternatives through managed connectors, replacing the fading system is a configuration and cutover exercise rather than a ground-up reintegration.
The cost you never see as a line item
The reason this is easy to under-invest in is that the cost of brittle integrations does not appear as its own line item. It is spread across engineering hours spent on maintenance, delayed launches, and the fulfillment errors that come from data getting out of sync between systems. Pipe17’s own analysis puts the drag from disconnected order systems at roughly 8 to 20% of fulfillment spend, showing up as wrong-warehouse routing, split shipments, and manual exceptions rather than as an invoice labeled “integration debt.”
A resilient stack keeps your vendors. You will always depend on a storefront, an ERP, warehouses, and carriers. What changes is where those dependencies are absorbed, so a change at any one vendor stays a contained event that the layer handles.
How to evaluate for resilience
A few questions separate a stack that survives churn from one that breaks on it. Who maintains each connection: your team, a contractor, or the platform vendor? When an endpoint changes its API, does something update centrally, or does a person have to notice and rebuild? If a fulfillment node goes dark, can orders reroute without code changes? Can you add a channel or a 3PL as a configuration step, or is it a new build every time? Do you have one place to see an order’s status across every system, or do you reconstruct it by checking each one?
The market underneath your order stack is going to keep consolidating. More platforms will be acquired, more providers will have a bad week, more vendors will refocus. The stacks that stay up through all of it are the ones designed on the assumption that their vendors will change, with the connections held in a layer built to change with them.
For the longer arc of how order management is moving from batch, per-system integration toward a real-time operations layer, see The Four Eras of Order Management.
