Most ERP integration projects fail in the scoping phase, not in the code. The code is the easy part — webhooks, GraphQL Admin API calls, idempotent sync jobs. The hard part is that nobody could agree on what the data flow actually was: which system is the source of truth for which field, what happens when both sides write the same record, and what “synced” even means when the ERP is down for maintenance at 2 a.m.
This post is the discovery checklist we run before writing a line of integration code. Answer these ten questions honestly and the project scopes itself. Skip them and the “simple” integration will find you again — usually during your first peak season.
Why ERP projects fail in scoping
- “Sync everything” — the unconstrained scope. Everything is a lot of fields, a lot of edge cases, and a lot of conflict resolution.
- Two systems of record. The ERP owns inventory, Shopify owns the storefront, but both think they own price. Every field needs exactly one owner, and the owner needs to be decided per field, not per system.
- No definition of “done” or “current.” When a webhook fails at 3 a.m., does the system retry? For how long? What does the operator see? A sync that fails silently is worse than no sync.
- The integration is built once, maintained forever. Nobody budgets the ongoing cost — new fields, new locations, ERP upgrades, Shopify API versioning.
The questions below exist to force these decisions into the open, on a whiteboard, before the contract is signed.
The ten questions
1. What is the direction of each data flow? Draw it. For every entity — products, inventory, orders, customers, prices, locations — which direction does data move: Shopify → ERP, ERP → Shopify, or bidirectional? Bidirectional flows need conflict rules; most entities don’t actually need to be bidirectional.
2. Which system is the source of truth for each field? Not each entity — each field. The ERP can own cost and purchasing data while Shopify owns the published price. Write the ownership matrix. Disagreement here is the #1 cause of mid-project rewrites.
3. What triggers a sync, and what’s the latency budget? Real-time via webhooks, near-real-time via scheduled polling, or batch nightly? Match the trigger to the business need: inventory must be near-real-time for a storefront that sells out; a nightly batch is fine for cost data. Decide this per flow, and set the latency budget explicitly so “it’s not synced yet” is a defined state, not a bug report.
4. What happens on conflict? Two systems wrote the same record since the last sync. Define it: last-write-wins, oldest-wins, or a manual review queue? For money and inventory, automatic conflict resolution needs an audit trail; for product descriptions, manual review is often cheaper.
5. What happens when the ERP is down? Not if — when. Maintenance windows, nightly batch jobs, regional outages. Define the queueing behavior: does Shopify buffer outbound events, does the integration retry with exponential backoff, and what’s the maximum acceptable staleness? And what does the merchant see during the outage — stale stock numbers on the storefront, or a warning?
6. What does an order in the ERP actually look like? An ERP order is not a Shopify order. Map the fields: line items, discounts, taxes, shipping, refunds, payment captures, gift cards, draft orders. Find the fields that don’t map cleanly — those are your mapping table’s real work, and they’re the part that always takes longer than estimated.
7. How do partial updates work? A customer edits their address; a line item is added to an order after fulfillment. Can the ERP handle partial updates, or does it require a full re-push? Partial-update support determines whether you can use granular webhooks or need reconciliation jobs.
8. What’s the reconciliation story? Syncs fail. The question is how you find out. Define a daily reconciliation job that compares totals — order count, inventory quantity per location, open orders — and alerts on drift. Reconciliation is the feature that makes an integration trustworthy, and the one most scope documents omit.
9. Who is on call when it breaks? The ERP vendor, the integration, Shopify’s API — three failure domains, usually three vendors. Decide who the merchant calls, who can read the logs, and who has the authority to pause syncs in an emergency. Document the runbook before go-live, not after the first incident.
10. What’s the testing and rollout plan? A sandbox-to-sandbox phase, then a shadow phase (sync real data without writing to the ERP), then a controlled go-live — usually one location or one market first. Decide the rollback trigger: what signal ends the rollout, and what does “rollback” actually restore? If you can’t define the rollback, you haven’t defined the risk.
How to run this discovery
Run these questions as a workshop, not an email thread. Invite the merchant’s operations lead, the person who actually processes orders, and the ERP vendor’s implementation person. The merchant’s answers and the vendor’s answers will differ — that difference is the scope. Write everything down, including the disagreements, and make the ownership matrix the appendix of the proposal.
A useful frame for the whole conversation: the integration is not “syncing two systems.” It is deciding, per field, who owns the truth, and building the machinery that makes the loser of each write eventually agree.
When to call in help
If you’re about to scope an ERP integration — or you’ve inherited a syncing-but-untrusted integration and the reconciliation gap is showing up as inventory surprises — an integration discovery session can run these ten questions, produce the ownership matrix and the flow diagram, and turn the proposal into something you can actually price and deliver. The code was never the risky part; a scoped discovery is what makes the project safe. Book a Commerce Architecture Review and bring your answers to these ten questions.