/ Operating model

Start with the operating model, not the connector.

Before selecting middleware or writing an API call, document how the business is supposed to work after launch. Follow one order from product setup through purchase, allocation, fulfillment, return and financial posting. Then follow inventory from receipt through availability, reservation, pick, cancellation and adjustment.

For each step, record the system that creates the fact, the system allowed to change it, every system that consumes it, the expected latency and the response when it fails. This produces a useful architecture instead of a list of logos.

Define a system of record for every business object. “The ERP is the source of truth” is too broad to implement. A product record contains different kinds of truth. The ERP may own cost and tax classification, a PIM may own descriptions and media, Shopify may own online merchandising, and the 3PL may own physically available stock. Ownership must be set at field or event level where responsibilities differ.

Once ownership is explicit, enforce it. A two-way sync in which both systems can overwrite price or inventory is not flexibility; it is an unresolved conflict. Prefer one authoritative direction for each field and define narrow exceptions with timestamps, priority rules and audit logs.

Build retries that do not create duplicates.

Retries are necessary because networks, APIs and downstream systems fail. Blind retries are dangerous because the first request may have succeeded even if the response was lost. Every write operation needs an idempotency strategy.

Create an idempotency key from a stable event or business operation, persist the outcome, and check it before repeating work. A Shopify order export might use the Shopify order ID plus an operation type and version. A fulfillment update might use the warehouse shipment ID. The exact key matters less than the guarantee that the same business action cannot be applied twice.

Classify errors before retrying:

Use a dead-letter queue or equivalent exception store, but do not let it become a graveyard. Every failed record should show business impact, age, attempts, payload references, owner and next action. Provide controlled replay after the cause is fixed.

/ Cutover runbook ( 10 )

Plan the cutover as a sequence of business boundaries.

The central cutover question is not “When does Shopify go live?” It is “At what exact point does each type of work stop entering the old pipeline and start entering the new one?” Orders, inventory, products, customer changes, fulfillments and returns may need different boundaries.

Create a migration and cutover runbook.

Define rollback before launch. Rolling back the storefront does not automatically reverse orders already sent to an ERP or 3PL. The plan must say what happens to new Shopify orders, inventory decrements and fulfillment events if traffic is returned to the old site. After a point of no return, forward-fixing may be safer than rollback.

Monitor business outcomes, not just HTTP status.

An integration can return successful API responses while producing the wrong operational result. Monitoring should cover four layers.

Every log line should carry correlation identifiers across Shopify, middleware, ERP and 3PL. Dashboards should separate normal retry noise from customer-impacting failure. Alerts need a threshold, route and playbook; otherwise they become background email.

Run reconciliation continuously after launch. Compare all Shopify orders with ERP/OMS acknowledgements, all released orders with 3PL receipts, fulfillments with Shopify updates, and inventory by SKU and location. Reconciliation is not an admission that webhooks failed. It is the control that proves the distributed system remains correct.

/ Checklist ( 16 )

A practical Shopify integration migration checklist.