Reference
What actually works
with Shopify Plus
One maintained reference rather than forty thin pages. This is the structural half: how systems connect to Plus, and where those connections break. The per-vendor rows are still being written.
Vendor-neutral by design. Where there is a commercial relationship it is stated on the page, because a reference that hides its incentives is not a reference.
Every commercial relationship, declared
This page recommends systems. A page that recommends systems while quietly earning from some of them is advertising. So, in full, as of July 2026:
Shopify. StoreBuilder Ltd is a Shopify Partner and earns referral commission when a merchant moves to or upgrades a Shopify plan through the practice. This is a real financial interest in the platform recommendation and it is the reason this page will tell a merchant when Shopify is the wrong answer — the value of being worth reading is larger than any single commission.
Everyone else: nothing. No ERP, WMS, OMS, stock-control or 3PL vendor pays this practice a referral fee, a commission or a rebate. No sponsored placements, no paid listings, no affiliate links. If that changes, the vendor's name and the arrangement appear here in the same sentence as the recommendation, not in a footnote.
Four ways a system connects, and what each costs you later
Vendors describe integration as a binary — supported or not. In practice there are four quite different arrangements behind that word, and which one a merchant ends up with matters more than the vendor's feature list.
Native connector, vendor-built
The system's own Shopify app, maintained by the vendor. Cheapest to stand up and the least flexible. The question to ask is which direction each field syncs and what happens when both sides change the same record.
Third-party middleware
An integration platform sitting between the two. Flexible, quick, and it introduces a third vendor, a third bill and a third place for the sync to fail. Fine as an answer; bad as an accident.
Bespoke integration
Built for this merchant against both APIs. Does exactly what is wanted and becomes something that has to be owned, monitored and updated when either side changes. The real cost is the second year, not the first.
File drop
Scheduled CSV exchange. Still common, still works, and honest about what it is — but it is batch, so the stock figure is always as old as the last run. Acceptable for slow-moving catalogues, dangerous on fast ones.
Where integrations break
Four failures, and none of them announce themselves. Each is a question worth asking before the architecture is chosen rather than during cutover — and the architecture is easier to choose once it is clear which system is holding stock truth and which is making the order promise.
Rate limits
Shopify's APIs are throttled. An integration that works fine against a test catalogue can fall behind on a real one, and the symptom is not an error — it is a queue that never quite catches up, which reads as "the stock is a bit out" rather than as a fault.
Sync lag versus sync failure
These need different alarms. A failed sync is loud and gets fixed. A sync running twenty minutes behind at the wrong moment oversells a product and nobody notices until a customer does. Ask what the acceptable lag is before choosing the architecture, not after.
Field-mapping ownership
The most expensive question in the room, and the one nobody asks: when the ERP and the store disagree about a product's weight, its tax class or its price, which one wins? Write that down per field. Projects that skip it discover the answer during cutover.
Nobody owning the join
The platform vendor supports their side, the systems vendor supports theirs, and the space between them belongs to whoever is standing closest. Under a prime contract that is the prime.
What this reference does not yet contain
The per-vendor detail — which specific ERP and warehouse systems UK merchants at this size actually run, how each one connects to Plus, what the integration costs to build and to run, and which are worth avoiding — is being written, and is not here yet.
It is not here because publishing a priced vendor matrix assembled from vendor marketing would be worse than publishing nothing. Those numbers are only worth having if they come from implementations, and they will appear named, dated and attributed as they do.
In the meantime the practical answer is the diagnostic: a straight read on what the operation needs, which usually eliminates most of the market in the first two questions.
Book the diagnosticTell us what is breaking
What the systems are doing now, and what you need them to do. We will tell you whether it is a platform problem or something cheaper.