- Storefront skill is not the same as owning Shopify-to-back-office middleware.
- Evaluate partners on data domains, order validation, failure recovery, and mapping ownership.
- Use a checklist of architecture, ops, and evidence questions—not theme portfolios alone.
- Score integration capability separately from UX/theme work in every RFP.
- Require a paid spike on one hard edge case before committing to full build.
When Shopify has to talk to an ERP, OMS, WMS, accounting system, or custom back office, the hard part is rarely the theme. The hard work lives in the middleware boundary: mapping data, validating orders before they land in operations, recovering from failures, and owning those mappings as your catalog and workflows change.
That is the transferable lesson for any business connecting Shopify to back-office systems. Theme and storefront partners matter. Integration partners are a different evaluation. You are hiring someone who can prove they own the glue between systems—not only the customer-facing layer.
This guide is a checklist for that evaluation. It is not a platform comparison and not a how-to for writing middleware tests or validators (we already published those lessons separately). Use it when you are selecting who builds and runs Shopify ↔ back-office integration.
Storefront skill is not integration skill
A strong Shopify theme or Hydrogen partner may still struggle with ERP order ingestion, inventory truth across locations, tax and shipping edge cases, or partial fulfillment. Those problems show up after go-live, when support tickets and operations teams absorb the cost.
Ask candidates to separate their work into two buckets:
Storefront and UX — theme, headless storefront, checkout UX, merchandising tools.
Integration middleware — sync jobs, webhooks, mapping, validation, retries, observability, and operational runbooks.
If a proposal collapses both into “Shopify build,” treat that as a signal. Integration ownership needs its own scope, acceptance criteria, and support model.
What “owning the middleware boundary” means
Ownership means the partner can explain—and show evidence for—four capabilities before you sign:
Data domains, not one-off scripts. Products, variants, customers, orders, inventory, locations, and facilities do not share the same lifecycle. Partners who think only in “sync jobs” often bury domain rules in shared helpers. Partners who think in domains can add a new entity without breaking the last one. For the engineering pattern behind that, see why ecommerce middleware tests should follow data domains.
Order validation at the integration boundary. Bad orders should fail early—before they become dirty ERP documents or half-fulfilled shipments. Ask where validation lives, what is rejected vs. repaired, and who gets alerted. The companion lesson is why ecommerce order validation belongs at the integration boundary.
Failure recovery you can operate. Timeouts, partial writes, duplicate webhooks, and rate limits are normal. Ask for replay/retry strategy, idempotency rules, dead-letter handling, and how operators resume a failed batch without inventing a spreadsheet process.
Mapping ownership over time. Catalog fields, metafields, taxonomies, and ERP codes change. Who owns the mapping document? How are changes reviewed? What breaks when Shopify or the ERP ships an API change?
For a concrete Shopify-to-ERP pattern (including furniture retail stacks that use STORIS), review Shopify and STORIS integration as an example of middleware-centered delivery—not as the only valid architecture.
Checklist: questions to ask every candidate
Use these in RFPs, discovery calls, and technical interviews. Good answers are specific. Vague answers about “we’ve done Shopify before” are not enough.
Scope and systems
Which back-office systems are in scope (ERP, OMS, WMS, accounting, PIM, CRM), and which system is source of truth for each domain?
Which sync directions are required on day one vs. later (Shopify → ERP only, bidirectional inventory, location/facility sync)?
What is explicitly out of scope for phase 1?
Middleware design
How do you separate data domains in code and tests so new entities do not inherit the wrong assumptions?
Where does order validation run, and what happens to rejected payloads?
How do you handle retries, duplicates, and partial failures without double-booking inventory or creating duplicate ERP orders?
Who owns mapping tables and how are mapping changes versioned and reviewed?
Operations and support
What dashboards, logs, or alerts do operators use when a sync stalls?
What is the runbook for replaying a failed order or inventory batch?
What SLAs cover after-hours incidents that block fulfillment?
Evidence, not slideware
Can you walk through a past middleware architecture (anonymized) including failure modes?
Can you show how tests cover source → middleware → destination paths for at least one domain beyond happy-path orders?
How do you respond when Shopify GraphQL or Admin API behavior changes under a live sync?
Red flags that look fine on a sales call
“We’ll use an iPaaS and configure it.” Platforms can help, but someone still owns domain rules, validation, and recovery. Ask who that someone is.
“Our theme team will handle the ERP.” Different skill set; different risk profile.
“We’ll sync everything nightly.” Latency and conflict rules matter. Nightly batches hide design gaps until peak season.
No talk of idempotency or replay. Production integrations fail; the plan must assume that.
No mapping owner after launch. Drift between Shopify and the ERP is inevitable without an owner.
How this differs from related decisions
Partner selection for Shopify ↔ back office is not the same as:
Structuring middleware tests by data domain — that is an engineering practice once a team is building (middleware tests and data domains).
Placing order validation at the boundary — that is a design rule for the integration itself (order validation at the integration boundary).
Choosing a general web development partner for a retail brand site — broader UX/CMS criteria, not middleware ownership.
Keep those distinctions clear so your RFP scores the right capability.
A practical shortlist process
Write a one-page domain map: systems, directions, and day-one entities.
Require a middleware architecture sketch and a failure/recovery sketch in every proposal.
Score candidates on the four ownership capabilities above, separately from storefront quality.
Run a paid discovery spike on one painful edge case (for example, split shipments, multi-location inventory, or tax-exempt B2B orders) before full build.
Define post-launch ownership: who changes mappings, who watches alerts, who ships API-change fixes.
Bottom line
Choose a Shopify integration partner the way you would choose an operations-critical vendor: prove they can own the middleware boundary—data domains, validation, recovery, and mapping—not only the storefront. When those proofs are weak, the cost shows up later in failed orders, inventory fights, and manual reconciliation.
If you are scoping Shopify-to-ERP work and want a second opinion on middleware ownership, start from the domain map and failure modes above, and use patterns like Shopify–STORIS integration as a reference for what “owned boundary” looks like in practice. You can also talk through your integration scope with Endertech.