There is a progression most growing D2C brands are told to expect. Start with Shopify Flow. Outgrow it, add an OMS. Outgrow that, graduate to an ERP. Three stages, increasing sophistication, a tidy story.
The story is wrong often enough to be expensive. These are not three stages of maturity. They are three architectural layers solving genuinely different problems, and a brand can need the third without ever needing the second — or run the second forever and never need the third.
The clearest evidence is the brands that buy an ERP because they have outgrown their OMS, then discover order operations got harder rather than easier. Nothing failed technically. They moved orchestration work into a system built for resource management.
So here is what each layer actually does, and how to tell which one your problems belong to.
Three layers, three jobs
Shopify Flow — the event layer
Flow reacts to things happening inside Shopify. An order is placed, a customer is tagged, a risk level is assigned, inventory crosses a threshold. It listens and it acts.
What it does well: tagging and segmentation, triggered notifications, flagging orders for review, inventory transfer triggers, anything where Shopify holds all the relevant state and the action is a single step.
Where it stops: decisions needing state Shopify does not have. Flow cannot easily ask "what does the vendor's stock look like right now" or "has this pincode failed delivery twice this month." It also has no clean concept of a multi-step transaction that must roll back — if step three fails, steps one and two have already happened.
Most brands under-use Flow before concluding they have outgrown it. It is worth exhausting properly first.
OMS — the orchestration layer
An OMS owns the order lifecycle across every system the order touches. It holds the authoritative record.
What it does well: reconciling order state when Shopify, the courier, the marketplace and the helpdesk all disagree. Deciding which warehouse or vendor fulfils. Managing exceptions as defined states rather than someone's judgment. Handling returns, partial fulfilment, and split shipments as first-class cases.
Where it stops: it is not an accounting system. It will tell you an order shipped from vendor B and was returned; it will not run your books, manage procurement, or handle manufacturing.
The signals that indicate you need this layer are specific, and we list all eleven in when a Shopify brand actually needs an OMS.
ERP — the resource layer
An ERP manages the enterprise: finance, procurement, manufacturing, accounting, HR, and the processes connecting them.
What it does well: general ledger, supplier and purchase-order management, production planning, multi-entity consolidation, statutory reporting.
Where it stops: high-volume D2C order orchestration. ERP order modules generally assume fewer, larger, invoice-driven B2B orders. They handle couriers, COD exceptions, and consumer returns awkwardly, because those were not the design target.
Why the progression myth persists
Two reasons, and both are structural rather than malicious.
Vendors sell upward. An ERP is a larger contract than an OMS. Positioning ERP as the next maturity stage is commercially sensible for the seller, and the framing gets repeated until it sounds like consensus.
"Outgrowing" gets misread. When operations hurt, it feels like the current system is too small, so the instinct is to buy something bigger. Usually the system is not too small — it is the wrong layer. A brand whose pain is vendor routing and inventory disagreement does not need a bigger version of Shopify Flow. It needs a different layer entirely.
Market guidance reflects this confusion. Commonly cited figures suggest dedicated OMS adoption around 5,000 to 10,000 orders monthly, earlier for multi-channel sellers, and note that beyond roughly 1,000 orders a day native Shopify functions as the system of record rather than the system of action. Useful as reference points — but they describe order volume, and the layer question is about the shape of your problems, not their quantity.
Mapping your problems to layers
Write down the five operational failures that cost you most this quarter. Assign each to a layer.
| If the failure involves... | The layer is |
|---|---|
| A Shopify event that should trigger an action | Flow |
| Manual tagging, segmenting, or flagging | Flow |
| Two systems disagreeing about an order's state | OMS |
| Humans deciding which warehouse or vendor fulfils | OMS |
| Exceptions handled case-by-case with no policy | OMS |
| Inventory truth across channels | OMS |
| Reconciling payouts, invoices, or vendor bills | ERP |
| Procurement and purchase-order approval chains | ERP |
| Manufacturing or production planning | ERP |
| Multi-entity financial consolidation | ERP |
Three patterns are worth naming.
Clustered in Flow — you likely have an under-configured Shopify rather than a missing system. Cheapest fix available.
Clustered in OMS — the orchestration layer is genuinely missing, and buying an ERP will not address it.
Split across OMS and ERP — this is real and common at scale. The answer is both, deployed with a clear boundary: the OMS owns order state, the ERP owns financial state, and one integration moves settled orders into the books. The failure mode is not running both; it is two systems each believing they own the same record.
Where Shopify Plus fits
Plus raises Shopify's ceiling without changing the layer structure. Checkout extensibility, B2B pricing, multi-storefront, higher API limits — all genuine, and all reasons some brands stay native longer.
What Plus does not provide is multi-vendor routing logic, cross-channel inventory truth, or an exception state machine. Those stay OMS concerns regardless of plan. Upgrading to Plus to solve an orchestration problem is the same category error as buying an ERP to solve one.
The cheapest correct first step
Before evaluating any product, map where the authoritative record for an order lives at each stage of its life. Placed — where? Paid — where? Allocated to a location — where? Handed to a courier — where? In transit — where? Delivered — where? Returned — where?
Most brands discover the answer changes three or four times, and that no single system owns it end to end. That map is usually enough to make the layer obvious, and it costs a few hours rather than a licence.
If the map shows ownership fragmenting mid-lifecycle, the orchestration layer is what is missing, and the next question becomes what it costs to build — which we break down in what a custom OMS actually costs.
If you want the mapping done with you rather than by you, book an operations architecture review. We trace the order lifecycle through your actual systems, mark where authority changes hands, and tell you which layer the problems belong to — including when the honest answer is that Flow can still do the job.
