How to Connect Shopify to ERP in 2026: A Step-by-Step Guide

A tradesperson in Darmstadt does not browse a website the way a shopper browses a fashion store. He opens his estimating software, imports a DATANORM file, and expects the price, the stock and the article number to already be correct because his margin depends on it. That is the world we walked into when H. Ludendorff GmbH, a consumer goods distributor in the German DACH market founded in 1924, asked us to build a Shopware storefront on top of roughly 1.2 million articles from more than 400 manufacturers. The moment you decide to connect Shopify to ERP, or Shopware to ERP as it was in their case, you stop building a website and start building a data-interchange system that happens to have a storefront attached.

We have done this enough times now, across Shopify, WooCommerce, Shopware and nopCommerce, to have strong opinions about what actually matters and what people waste money on. This guide is those opinions, in the order we run the work.

TL;DR

• Sync scope before tooling: The single biggest driver of cost and pain is not which connector you buy, it is deciding which direction each piece of data flows and who owns the truth. Get the sync matrix right and the integration is boring; get it wrong and no amount of middleware saves you.
• Our position, stated plainly: For most mid-market stores the answer is not a real-time bidirectional sync of everything. We disagree with the standard advice that ERP integration means the two systems mirror each other constantly. In our experience you sync a small set of fields on a schedule, keep one system of record per field, and resist the temptation to make everything live.
• Catalogue scale and data shape decide the timeline: A 2,000-SKU store with clean data is a two-to-four week job. A 1.2M-article catalogue with manufacturer feeds, variant explosions and VAT edge cases is a multi-month data project. Scope the catalogue before you quote the integration.

Step 1: Map what actually needs to sync before you touch a connector

The first thing we do when a store like this lands on our desk is refuse to talk about tools. Clients arrive asking whether they should buy a specific connector, and we redirect the conversation to a whiteboard with two boxes, Shopify on one side and the ERP on the other, and arrows between them. Every arrow is a decision. Every decision has a cost.

When Ludendorff came to us, the instinct on the table was ambitious: sync everything, both directions, in real time. That is the default fantasy and it is almost always wrong. With 1.2 million articles sourced from 400-plus manufacturers publishing in DATANORM, “sync everything in real time” would have meant a firehose of updates that nobody could reason about when it broke. So we started by drawing the sync matrix.

What goes in a sync matrix?

A sync matrix is a table with one row per data object and columns for direction, source of truth, frequency and trigger. It sounds trivial. It is the single most valuable artefact in the whole project, and the one clients most often skip.

Data object	Direction	Source of truth	Frequency	Trigger
Product catalogue (base data)	ERP to store	ERP	Nightly batch	Scheduled
Prices	ERP to store	ERP	Nightly, hourly for changes	Scheduled + delta
Stock levels	ERP to store	ERP	Every 15 min	Scheduled
Orders	Store to ERP	Store	Near real time	Order placed
Customer records	Bidirectional (careful)	Depends on field	On change	Event
Fulfilment / tracking	ERP to store	ERP	On update	Event

Notice how little of that is bidirectional. In our experience, the only object that genuinely needs to flow both ways is customer data, and even there you split it by field: the store owns marketing consent, the ERP owns credit terms and tax classification. Trying to make both systems authoritative over the same field is how you end up with two “correct” prices that disagree and a support queue full of angry tradespeople.

Who owns the truth for each field?

This is the question that quietly decides your architecture. For Ludendorff, the ERP owned everything upstream of the storefront because that is where the DATANORM ingestion lived: prices, stock, article numbers, manufacturer relationships. Shopware, or Shopify in a comparable build, owned the presentation layer and the order intake. Orders flow back into the ERP, and the ERP flows fulfilment status back out.

Pro Tip: When a client insists a field must be editable in both systems, ask them what happens at 2am when both systems update it in the same window. On the Ludendorff build we had exactly one field where the client swore they needed dual ownership, a promotional price override. We solved it by giving the store a temporary override flag that the nightly ERP sync respects rather than overwrites, so the ERP stays authoritative but a merchandiser can still run a weekend promo without a developer. That single design decision saved us weeks of conflict-resolution logic.

The reason we are this strict is that we have watched integrations rot. A store where nobody can say which system is right about a price is a store that will eventually stop trusting its own data, and once the team stops trusting the sync they start doing manual overrides, and manual overrides are how you end up back where you were before the integration.

Checkpoint: You have a filled-in sync matrix that every stakeholder has read, and for every single field in it exactly one system is named as the source of truth with no ties.

Step 2: Audit your ERP export before you promise anyone a date

We have a rule internally that came from being burned: never quote an ERP integration until we have seen a real export file from the client’s actual system, not a sample, not documentation, the real thing with real data.

The reason is that ERP documentation describes the system the vendor sold. The export describes the system your client has actually been using for fifteen years, with all the workarounds, the free-text fields that should have been dropdowns, and the product that someone entered with a comma where a decimal should be. Documentation will tell you prices are exported as decimals. The file will show you the one supplier whose prices come through as strings with a currency symbol baked in.

The things that break, in the order we usually find them

On the Ludendorff DATANORM ingestion, the export broke in ways that were entirely specific to their catalogue. DATANORM is a German trade standard for exchanging article data, and while it is well specified, 400-plus manufacturers implement it with 400-plus interpretations. Some sent full product data, some sent price updates only, some sent article numbers that collided across suppliers. We built a normalization layer whose only job was to make 400 dialects speak one language before anything reached the store.

The VAT problem is worth naming specifically because it recurs on almost every European integration we do. On more than one build the ERP exported prices with a VAT flag that was either wrong or ambiguous, net where we expected gross, or a reduced rate applied to a product category that should have been standard. If you sync that straight into the storefront you sell at the wrong price, and in a B2B context you can do that thousands of times before anyone notices, because B2B buyers are used to seeing net prices and do not question them.

Here is the audit checklist we run against every export before we commit to a timeline:

• Encoding: Confirm the file encoding and check for mangled special characters, umlauts and accented names are the usual casualties.
• Price format: Verify whether prices are net or gross, which currency, and whether the decimal separator is a comma or a period.
• VAT flags: Confirm the tax class per product and reconcile it against a sample of known-correct prices.
• Identifier stability: Check that article or SKU numbers are unique and stable across exports, not regenerated each time.
• Variant structure: Count how the export represents variants and confirm it matches how the storefront needs them grouped.
• Empty and null handling: Decide explicitly what an empty field means, no change or delete, because they are not the same thing.

Pro Tip: We now budget a dedicated data audit phase as a separate, fixed-fee line item before the integration build, precisely so the client understands that finding the garbage is work, not an afterthought. On a spec-driven catalogue like Ardon Adria, a Croatian workwear and PPE supplier we build for, the specs themselves are the product: protection ratings, sizing, certification classes. If the certification class comes through the feed inconsistently, you are not selling PPE, you are selling a lawsuit. We treat spec fields with the same audit rigour as prices.

Checkpoint: You can take a real export file, run it through your normalization step, and produce a sample of, say, fifty products that a human on the client side confirms are correct down to the price and tax.

Step 3: Choose the integration pattern, not just the tool

Now, and only now, do we talk about tools. Clients want to start here because it feels like progress, but choosing a connector before you know your sync matrix and your data shape is like buying a van before you know what you are hauling.

There are three broad patterns to connect Shopify to ERP, and they are not interchangeable.

Pattern	Best for	Complexity	Rough timeline (Presta estimate)	Trade-off
Off-the-shelf connector	Standard catalogues, common ERPs, few custom fields	Low	1-3 weeks	Cheap and fast, but you bend your process to its assumptions
iPaaS / middleware	Multiple systems, some custom logic, scheduled syncs	Medium	4-8 weeks	Flexible, ongoing subscription, someone must own the flows
Custom integration layer	Huge or unusual catalogues, non-standard ERP, heavy transformation	High	8+ weeks	Full control, highest cost, you own maintenance

Those timelines are our estimates from scoping and past projects, not measured guarantees, and they assume the data audit in Step 2 is already done. The audit is the variable that blows every one of these estimates up.

When does an off-the-shelf connector actually work?

More often than agencies like to admit. If you are on a mainstream ERP, your catalogue is a few thousand SKUs, and your data is clean, a marketplace connector genuinely does the job and we will tell you to buy it rather than pay us to build one. We are not precious about writing code for the sake of it. Shopify’s own connector ecosystem for the major ERPs is mature, and you can review Shopify’s app marketplace to see what fits your specific system before you talk to anyone.

The line where off-the-shelf stops working is transformation. The moment your data needs meaningful reshaping between the two systems, variants that must be regrouped, prices that must be recalculated per customer group, feeds from many suppliers that must be normalized, a generic connector fights you, and you spend more configuring around its assumptions than you would have spent building the flow you actually needed.

Why we built custom for Ludendorff

The Ludendorff catalogue was never going to fit a connector. You cannot buy an off-the-shelf tool that ingests DATANORM from 400 manufacturers, normalizes their dialects, resolves article-number collisions and publishes 1.2 million articles into a Shopware storefront while keeping stock accurate. That is a custom integration layer by necessity, not by preference. We would have loved to save them the cost of a bespoke build. The catalogue would not allow it.

For contrast, when we tweaked an existing Shopify store for Beberusha, a baby and childcare retailer, the right move was the opposite: no heavy integration at all. Their revenue went up 30% in the first month from focused storefront work, not from wiring in an ERP they did not need. Knowing when not to integrate is as much a part of this job as knowing how.

Checkpoint: You have chosen a pattern, and you can articulate in one sentence why the two cheaper patterns were rejected, or why the more expensive one is unnecessary.

Step 4: Build the sync in the safe direction first

Sequencing an integration is where experience earns its fee. There is a correct order to switch these flows on, and it is not the order clients ask for. Clients want orders flowing into the ERP first because that is the flow that touches money. We do it last, on purpose.

The principle we follow, and the one we brief every client on, is what we call the Read-Before-Write Rollout. It has four steps and a boring-on-purpose name because it describes exactly what it does.

1. Read-only catalogue sync: Push product, price and stock data from the ERP into the store, one direction, nothing writes back. If this breaks, the worst case is a wrong price on a staging store nobody has seen.
2. Read-only reconciliation: Run the catalogue sync against a copy of production data and diff it against what the client believes is true. This is where the VAT flags and the collisions surface.
3. Write path in staging: Turn on orders flowing back to the ERP, but into a test company or sandbox in the ERP, so real orders never touch the live financial system until the mapping is proven.
4. Controlled go-live: Switch the write path to production with a rollback plan and a human watching the first day of orders land in the ERP by hand.

The logic is simple: reads are recoverable, writes are not. A wrong price you can fix and re-sync. An order that posted to the ERP with the wrong tax class has already generated an invoice, and now you are cleaning up an accounting problem, not a code problem. For a pharma distributor like Vemax, where the client handles representation, registration, import and distribution of medicines and medical devices across Serbia, Montenegro, North Macedonia, Bosnia and Albania, a bad write is not just an accounting mess, it is a regulatory one. We built their state-of-the-art store, and their revenue grew 180%, and none of that would have survived a go-live where orders posted incorrectly into a regulated distribution system on day one.

The reads are recoverable and the writes are not. Build the safe direction first, prove it, and only then let the store write into the system that generates money.

How do you test a sync without breaking production?

You clone. Every serious ERP has a way to create a test company or sandbox environment, and if the client’s does not, that is a red flag we raise before signing. We run the entire integration against the sandbox until the diff between what the store shows and what the ERP holds is zero across a representative sample. Only then do we point the same code at production.

This maps onto how we run every build, the same journey of a new website discipline we apply to design and development: staged, reviewed, nothing goes live until the previous stage is signed off. Integrations are not special. They just have higher blast radius.

Checkpoint: Orders placed on staging appear correctly in the ERP sandbox, with the right tax class, customer group and line items, and a client-side finance person has confirmed a sample by hand.

Boost Revenue Without Betting the Business on a Big Bang Launch

If you are staring at an ERP integration and a catalogue that scares you, this is exactly the work our ecommerce team does day to day: Shopify, WooCommerce and Shopware builds, platform migrations, and the ERP and feed integrations that sit under them. We are a good fit if you have real catalogue complexity, spec-driven products or multi-supplier data, and you want the sync built by people who have already met DATANORM and VAT-flag surprises. We are not the right call if your store is a few hundred clean SKUs and an off-the-shelf connector already covers you, and we will tell you that on the first call rather than sell you a project you do not need. If you are somewhere past that line, talk to Presta’s ecommerce team and bring a real export file.

Step 5: Handle variants, pricing tiers and the edge cases that eat timelines

This is the step where the estimate we gave the client and the reality of the catalogue meet, and it is usually where they diverge. We will be candid: we have quoted variant-heavy catalogues too optimistically before. On an earlier build, not Ludendorff, we scoped a catalogue sync at three weeks and it took five, and the entire overrun was variants. The export represented a single product with three attributes as a flat list, and reconstructing the variant hierarchy so the storefront could display it correctly was most of the extra fortnight. We now add a variant-complexity multiplier to any estimate the moment we see more than three attributes per product.

Why do variants break syncs so reliably?

Because Shopify and most ERPs disagree about what a variant even is. Shopify has a hard limit on variant combinations per product, which for years sat at 100 and is worth checking against the current Shopify product limits documentation before you promise a client anything. An industrial ERP does not think in those terms at all; it thinks in article numbers, and a “variant” is often just another article number with a relationship you have to infer. Reconstructing that relationship from the export is real work, and it is work that does not show up until you actually try to build the product page.

On Ardon Adria’s spec-driven PPE catalogue, sizing is a variant axis, protection class is a filter, and certification is a hard fact that must never be presented incorrectly. We built the sync so that sizing generated Shopify variants, while protection class and certification came through as structured metafields that drive filtering and are locked to the ERP as source of truth. Mixing those up, treating certification as a free-text variant option, would let a merchandiser accidentally edit a legal safety rating in the store admin. The specs are the interface, so we made the interface impossible to corrupt.

Pricing tiers and customer groups

B2B pricing is where a lot of Shopify-to-ERP projects quietly fail. The ERP holds negotiated prices per customer or customer group, and the storefront has to show the right price to the right logged-in buyer. This is a solvable problem, but it changes your sync fundamentally, because now prices are not one value per product, they are a matrix of product-by-customer-group, and that matrix can be large. We sync it as a separate object on its own schedule, and we cache aggressively, because recalculating a full price matrix on every page load will bring the store to its knees.

Here is the framework we use to decide how a given field should be modeled:

• Single value, rarely changes: Sync as a plain product field on the nightly batch.
• Single value, changes often: Sync on a delta trigger so only changed records move.
• Matrix by customer group: Sync as a separate object, cache in the store, invalidate on change.
• Legally or regulatorily fixed: Sync one direction, lock in the store admin, ERP is the only writer.

Checkpoint: A logged-in B2B customer from a specific price group sees their negotiated price, a variant-heavy product renders every valid combination, and no locked field can be edited in the store admin.

Step 6: Instrument the sync so failures are loud, not silent

The worst integration failure is not the one that crashes. It is the one that keeps running while quietly syncing garbage, because nobody notices until a customer does. We build every sync with the assumption that it will fail, and the only question is whether it fails loudly or silently.

Our systematic approach to debugging applies directly here: you cannot fix what you cannot see, and you cannot see a sync that has no instrumentation. So we instrument three things by default.

First, a heartbeat. Every scheduled sync reports that it ran, on time, with a record count. If the nightly catalogue sync usually moves 1.2 million article checks and one night it moves zero, an alert fires before anyone opens the store. Silence is treated as failure, not as success.

Second, a reconciliation diff. On a schedule, we compare a sample of store data against the ERP and flag anything that has drifted. Drift is inevitable over months; the point is to catch it in dozens of records, not thousands.

Third, a dead-letter queue for orders. If an order cannot post to the ERP, it does not vanish and it does not silently retry forever. It lands in a queue a human can see, with the error attached, and the store keeps taking orders while that one is investigated. We learned this the hard way: an early integration retried a failing order silently, the retry logic had a bug, and we lost a day of order data to the ERP before anyone realized the queue had backed up.

Here is what we monitor and the threshold that triggers a human:

• Sync heartbeat: Alert if a scheduled sync misses its window by more than one cycle.
• Record volume: Alert if a sync moves far fewer or far more records than the rolling average.
• Failed writes: Alert immediately on any order that fails to post, and hold it in the dead-letter queue.
• Price drift: Alert if reconciliation finds any priced product where store and ERP disagree.
• Stock drift: Alert if oversell risk appears, store shows stock the ERP says is gone.
• Feed staleness: Alert if a manufacturer feed has not updated within its expected interval.

Checkpoint: You can deliberately break the sync in staging, unplug a feed, feed a malformed price, fail an order write, and confirm that each failure produces an alert a human will actually see.

Step 7: Measure the right things at 30, 60 and 90 days

An ERP integration is not “done” at go-live. It is done when the team stops doing manual work they used to do, and when the numbers the business cares about start moving. We agree the measurement plan with the client before go-live, because a metric you define after launch is a metric you defined to make yourself look good.

Timeframe	What we measure	What good looks like
30 days	Sync reliability, manual-intervention count, order-post success rate	Syncs run unattended, order-post success near 100%, manual price edits trending to zero
60 days	Data drift, oversell incidents, support tickets tied to wrong price or stock	Drift caught by reconciliation not customers, oversells rare and explainable
90 days	Operational time saved, catalogue coverage, revenue impact	Team reclaims the hours previously spent on manual catalogue work, full catalogue live, revenue trend visible

The 30-day window is about trust. If the team still logs into the ERP every morning to check the store did the right thing overnight, the integration has not landed emotionally even if it is technically working. We watch the manual-intervention count obsessively in month one, because it is the honest signal of whether people believe the sync.

By 90 days the business number is what matters, and this is where the proof lives. Ludendorff’s Shopware store with ERP integration increased their revenue by 80%, and that number is only possible because the catalogue actually made it online correctly, all of it, priced right, in stock, importable by tradespeople who trust the data. Vemax’s regulated pharma store grew revenue 180% over a longer run, and Beberusha’s focused Shopify work delivered 30% in the first month. Different shapes of engagement, the same underlying truth: revenue follows data the customer can trust.

We do not attach a revenue promise to an integration project, and we tell clients that directly. What we can commit to is the operational outcome, hours reclaimed, drift caught, oversells eliminated, and in our experience the revenue follows once the store stops lying to customers about price and stock.

Checkpoint: At 90 days you can show a before-and-after on manual hours, a drift log that trends down, and a revenue line the client’s finance team recognizes as real.

Common Mistakes

Mistake: Treating the integration as a technical project instead of a data project. Why It Happens: Teams focus on the connector and the API because that is the visible, code-shaped part, while the messy catalogue data feels like someone else’s problem. Fix: Run the Step 2 data audit as a paid, scheduled phase before any build, and refuse to quote the integration until you have seen a real export file.

Mistake: Making everything bidirectional and real time because it sounds robust. Why It Happens: “Real-time two-way sync” sounds like the premium option, so clients ask for it and agencies who want the bigger invoice do not push back. Fix: Default to one direction per field with a single source of truth, sync on a schedule, and only make a field bidirectional when you can answer what happens when both systems write it at once.

Mistake: Going live with the write path first because orders feel most urgent. Why It Happens: Orders touch money, so instinct says wire them up immediately, and staging the read path first feels like a delay. Fix: Follow the Read-Before-Write Rollout, prove catalogue reads and reconcile them, then post orders into an ERP sandbox before ever touching the live financial system.

Advanced tips for teams already running a sync

If you already have a working integration and you are here to harden it, the leverage is in three places most teams neglect.

Version your mappings. The field mapping between your store and your ERP is code, and it should live in version control with a changelog, not in a middleware UI where someone can silently change a rule at 5pm on a Friday. When a price starts syncing wrong six weeks later, you want to diff the mapping history, not guess.

Build a replay capability. When a batch of orders fails to post because the ERP was down for maintenance, you want to replay that exact batch from the dead-letter queue, in order, without duplicating. Idempotency, the property that replaying the same message twice does no harm, is the difference between a five-minute recovery and a day of manual reconciliation.

Separate reference-data sync from transactional sync. Product and price data change on a slow, predictable rhythm. Orders and stock move fast and unpredictably. Running them on the same pipeline means a slow catalogue batch can block an urgent stock update. Split them, and give the fast, business-critical flows their own lane. This is the same instinct behind why agile methodology matters when building startups: small, independent pieces you can change and ship without holding everything else hostage.

One more, on outsourcing the maintenance versus keeping it in-house. A sync is not a build-and-forget asset; feeds change, ERPs get upgraded, manufacturers change their DATANORM dialect. If you do not have someone who owns the integration the way a gardener owns a garden, it will decay. That ongoing ownership is a real reason to work with an experienced agency rather than treat the integration as a one-time capital expense.

• Version control: Keep field mappings and transformation rules in a repo with a changelog.
• Idempotency: Make every write safe to replay so recovery never duplicates orders.
• Pipeline separation: Isolate slow reference-data syncs from fast transactional ones.
• Ownership: Name a specific person or partner who owns the sync’s long-term health.

To close the loop on Ludendorff: what made that engagement work was not the Shopware build itself, impressive as a 1.2M-article state-of-the-art store is, it was that we treated the whole thing as a data-interchange project wearing an ecommerce hat from day one. The 80% revenue increase came from tradespeople being able to trust the catalogue enough to import from it. If we did it again, we would push even harder to run the data audit as a distinct paid phase up front, because on that project the audit findings quietly reshaped the timeline and we would rather set that expectation on day one than discover it in week three.

If you are just getting started, prioritize the sync matrix and the data audit above everything, they are cheap to do and they prevent the expensive mistakes. If you are auditing something that already exists, start with instrumentation: turn on the heartbeat, the reconciliation diff and the dead-letter queue, because you cannot fix drift you cannot see, and most struggling integrations are struggling silently.

Next Steps:

• Draw your sync matrix: one row per data object, and name a single source of truth for every field.
• Pull one real export file from your ERP and run the Step 2 audit against it before quoting anyone a timeline.
• Turn on a sync heartbeat and a reconciliation diff on any integration you already run, so the next failure is loud.

Frequently Asked Questions

How do I connect Shopify to an ERP system?

You connect Shopify to an ERP in one of three patterns: an off-the-shelf connector, an iPaaS middleware layer, or a custom integration. Which one is right depends on your catalogue size, how much your data needs reshaping between the two systems, and how standard your ERP is. In the most common mid-market case, a mainstream ERP with a few thousand clean SKUs, an off-the-shelf connector is the correct answer and we will tell you to buy it rather than build.

The part that matters more than the tool is the sync design. Before you connect anything, decide which data flows in which direction and which system is the source of truth for each field. Products, prices and stock almost always flow from the ERP to the store; orders flow from the store back to the ERP. Get that matrix right and any of the three patterns will work. Get it wrong and no tool will save you.

We always start with a read-only catalogue sync, prove it against real data, and only then turn on the order write path, because a wrong price you can fix and re-sync, while a wrong order has already generated an invoice.

What tools are needed to connect Shopify to ERP?

At minimum you need a way to move data between the two systems on a schedule, and a way to see when that movement fails. For standard setups that can be a single connector app from the Shopify marketplace. For anything with real transformation, feeds from multiple suppliers, per-customer pricing, variant reconstruction, you need either a middleware platform or a custom integration layer, plus monitoring.

Do not underestimate the monitoring tools. A sync with no heartbeat, no reconciliation diff and no dead-letter queue for failed orders is a sync that will fail silently, and silent failure is the expensive kind. We consider instrumentation part of the required toolset, not an optional extra.

You will also need access to an ERP sandbox or test company. If your ERP cannot give you one, that is a constraint to solve before you start, because testing the order write path against a live financial system is not something we are willing to do.

Can I integrate Shopify with my existing ERP?

Almost certainly yes. In fifteen years we have not met an ERP we could not integrate with, though the how varies enormously. Mainstream ERPs have well-documented APIs and mature connectors. Older or more specialized systems may only offer file-based exports, DATANORM, CSV, XML, in which case you build a normalization layer that turns those files into clean data before it reaches the store.

The real question is not whether it is possible but what shape the integration takes. The determining factor is your data, not your ERP’s brand. We have integrated Shopify, Shopware and nopCommerce storefronts with a wide range of back-end systems, and every time the timeline was driven by the state of the catalogue export, not by the logo on the ERP.

Bring us a real export file and we can usually tell you within a day whether it is a two-week connector job or a multi-month data project. The file is more honest than any documentation.

How long does a Shopify ERP integration take?

For a clean, standard catalogue on a mainstream ERP with an off-the-shelf connector, our estimate from past projects is one to three weeks. For a middleware build with some custom logic, four to eight weeks. For a large or unusual catalogue needing a custom layer, eight weeks and up. Those are Presta estimates from scoping, not guarantees, and they all assume the data audit is already done.

The single biggest variable is data quality, and specifically variants and pricing complexity. We have overrun our own estimate on a variant-heavy catalogue before, three weeks that became five, entirely because the export represented variants as a flat list we had to reconstruct. We now add a variant-complexity multiplier the moment we see more than three attributes per product.

If someone quotes you a fixed timeline without asking to see your export file, be skeptical. They are quoting the happy path, and your catalogue almost certainly has an unhappy path in it somewhere.

Do I even need an ERP integration, or can I manage manually?

Plenty of stores should not integrate, and we say so on the first call. If your catalogue is small, your prices rarely change and your order volume is manageable by hand, an integration is cost you do not need to spend. We tweaked an existing Shopify store for a baby and childcare retailer and grew their first-month revenue by 30% with focused storefront work and no ERP wiring at all, because that is what the situation called for.

The threshold where integration becomes worth it is roughly when manual data entry starts causing errors or eating meaningful staff time, when you oversell because stock is not synced, or when you have per-customer B2B pricing that a human cannot maintain by hand. At that point the integration pays for itself in reclaimed hours and avoided mistakes.

Our honest test: if your team logs into the ERP every morning to reconcile the store by hand, and that reconciliation takes real time and catches real errors, you have crossed the threshold. Below that, keep your money.

When does it make sense to bring in an agency like Presta for this?

Not every store needs us, and we would rather you knew that up front. If your setup fits an off-the-shelf connector and your data is clean, you can do this yourself with a good app and a careful afternoon. There is no shame in the simple path, and we prefer it for you when it fits.

It becomes worth bringing in our ecommerce team when the catalogue has real complexity: multiple supplier feeds, non-standard exports like DATANORM, variant explosions, per-customer pricing matrices, or regulatory constraints where a wrong price or a bad order write is more than an inconvenience. That is the work we do across Shopify, WooCommerce and Shopware, and it is where fifteen years of having already met these specific failures actually saves you money rather than costs it.

The other moment to call us is when you already have an integration and it is decaying, drifting silently, failing without alerts, requiring manual patches. Hardening an existing sync is often a smaller engagement than clients expect, and it buys back a lot of peace.

What is the most common thing that goes wrong?

VAT and price flags, on European integrations especially. The ERP exports a price with a tax flag that is wrong or ambiguous, net where you expected gross, or a reduced rate on a category that should be standard, and if you sync it straight through you sell at the wrong price. In B2B you can do that thousands of times before anyone notices, because buyers expect net prices and do not question them.

The second most common is silent sync failure: a scheduled job stops running or starts syncing garbage, and because there is no heartbeat and no reconciliation, nobody notices until a customer complains. Both of these are preventable, one with the data audit, one with instrumentation, and both are cheaper to prevent than to clean up.

How do you keep the integration working over time?

Someone has to own it. Feeds change, manufacturers change their export dialects, ERPs get upgraded, and Shopify itself ships changes. An integration is a garden, not a statue. We version-control the field mappings so we can diff them when something drifts, we build replay capability so a batch of failed orders can be re-posted safely, and we separate slow reference-data syncs from fast transactional ones so one cannot block the other.

The practical decision is whether that ownership lives in-house or with a partner. If you have an engineer who understands the sync and watches the alerts, keep it in-house. If you do not, the maintenance is a real reason to keep an agency on a light retainer, because the cost of a silently broken sync over three months usually dwarfs the cost of someone watching it.

Sources

• Shopify App Store
• Shopify product and variant limits documentation