ERP Integration During a Magento-to-Shopify Migration: NetSuite, SAP & Dynamics, Explained

When a B2B operation scopes a Magento-to-Shopify migration, the ERP integration is the line item the IT stakeholder circles first, and rightly. The storefront is replaceable; the connection between commerce and the system that runs the company is what keeps orders flowing, inventory honest, and finance reconciled. This is the technical explainer of what actually happens to that connection during the migration: why the existing integration cannot move, what Shopify's integration surface looks like to someone who has only built against Magento, and how the mapping works for the three ERPs we see most, NetSuite, SAP, and Microsoft Dynamics.

Quick answer: The Magento-ERP integration does not migrate; it gets rebuilt, because the two platforms invert the architecture. Magento integrations live inside the platform, custom modules with database access, observers, and cron jobs, coupled to a Magento version. Shopify is closed SaaS: no database access, no code on the platform, so the integration becomes an external service speaking to Shopify's Admin API, driven by webhooks instead of observers, with rate limits and bulk operations as design inputs rather than afterthoughts. The rebuild is also the exit from the fragility that made the old integration a maintenance liability.

Why the Integration Cannot Move

A typical Magento-ERP integration is code that lives where the storefront lives. It reads and writes the Magento database directly or through internal APIs, hooks order events with observers, runs syncs on cron, and depends on the platform's schema staying put. That design is why every Magento upgrade triggers an integration risk assessment, and why the module often outlives the understanding of it.

None of that architecture has anywhere to land on Shopify. There is no server to deploy to, no database to query, no schema to couple against. Everything enters and leaves through APIs. So the migration question is never "how do we port the module." It is "what did the module actually do," expressed as data flows, and "how do those flows run as an external service against Shopify's surface." The first half of that question is the field-mapping exercise from the B2B migration checklist; this article is the second half.

Shopify's Integration Surface, for People Who Know Magento's

Five things define the environment the rebuilt integration lives in, and each replaces a Magento habit.

The Admin API replaces database access. All reads and writes go through Shopify's GraphQL Admin API, which models everything the integration touches: products and variants, inventory by location, orders, customers, and the B2B objects, companies, company locations, catalogs, and price lists, that carry the wholesale structure.

Webhooks replace observers. Where a Magento module hooked order placement internally, the external service subscribes to webhook topics and receives events over HTTP. The design consequence: the integration has to be built for at-least-once delivery, idempotent processing, and reconciliation sweeps that catch anything a missed webhook would otherwise lose.

Rate limits replace unbounded loops. The Admin API is rate-limited by calculated query cost, which makes throttling a first-class design input. Syncs that hammered the Magento database in a tight loop become queued, batched jobs that respect the cost budget.

Bulk operations replace overnight table writes. For catalog-scale work, tens of thousands of items, full price-list refreshes, Shopify's bulk operations API is the intended path, and integrations that page through standard queries for six-figure catalogs are fighting the platform instead of using it.

Metafields replace schema extensions. The ERP fields with no native Shopify home, technical attributes, account codes, plant or branch designations, land in metafields, which is the deliberate version of what column additions and EAV attributes did on Magento.

The net effect is worth stating plainly for the buyer evaluating this: the constraints are real, and they are also why the rebuilt integration stops breaking. An external service against a versioned public API survives platform updates on both sides in a way an in-platform module never did.

NetSuite to Shopify

NetSuite integrations typically speak SuiteTalk or REST, with SuiteScript handling ERP-side logic and saved searches feeding data extraction. The mapping work concentrates in three places. The item master: NetSuite items, including matrix items, map to Shopify products and variants, with the decision of which item attributes become variant options versus metafields made once, deliberately. Pricing: NetSuite price levels and customer-specific pricing map onto Shopify price lists attached to company accounts, which is where the Magento customer-group structure finds its new home. And the order cycle: Shopify orders create NetSuite sales orders under the right customer and terms, with fulfillments and invoices flowing back so buyers see status and history without calling anyone.

The recurring judgment call: which pricing mirrors to Shopify as price lists, and which stays NetSuite-calculated behind a quote flow, stable negotiated rates mirror well, heavily conditional pricing does not.

SAP to Shopify

SAP environments, whether ECC, S/4HANA, or Business One, bring the strongest middleware tradition of the three, IDocs, BAPIs, and OData services, often already flowing through an integration layer. The commerce-relevant mapping centers on the material master (materials to products, with SAP's richer classification data landing in metafields), stock by plant or storage location mapping to Shopify locations, and the document flow: order to sales document, delivery and billing documents back to Shopify as fulfillment and invoice status.

Pricing deserves its own sentence, because SAP condition records can express pricing logic far beyond what any commerce platform should replicate. The working rule is the one that holds across B2B sync architecture: mirror the stable outcomes as price lists, and route anything condition-dependent through a quote or draft-order path where SAP stays the calculator. Attempting to rebuild condition logic storefront-side is how integrations become the second unmaintainable system.

Microsoft Dynamics to Shopify

Dynamics 365, Business Central for the mid-market, Finance and Operations above it, exposes OData and Dataverse-based APIs that make the entity mapping comparatively direct: customers and their price lists to companies and Shopify price lists, items and variants to products, warehouses to locations, sales orders and invoices in the familiar two-way cycle. Legacy GP and NAV environments add an extraction layer question, but the target-side design is the same. As with the other two, the field-level inventory decides the project: which of the ERP's customer and item fields the storefront genuinely needs, in which direction each flows, and which system owns the truth for it.

The Cutover Sequence for the Integration Itself

The integration rebuild has its own migration-within-the-migration, and its sequencing is what protects order flow.

The old module keeps serving Magento until cutover; nothing about the migration touches it. The new integration is built and run against the Shopify environment in parallel, syncing the real item master, real price lists, and real inventory into staging until the flows reconcile, and reconciliation here means line-level: test orders placed in Shopify staging arrive in the ERP with the right customer, terms, quantities, and references, and fulfillment and invoice data returns correctly. Cutover then becomes an ordering question rather than an integration question: order-number continuity and reference mapping agreed with finance beforehand, a defined freeze window if one is needed at all, and the first days of live orders reconciled against the ERP line by line. The old module is retired only after the new flows have carried real volume.

What Maintainable Means After Magento

The promise the rebuild has to keep is the one the Magento module broke: surviving change on both sides. That comes from the architecture above, an external service against versioned APIs, plus ownership of the unglamorous parts: API version upgrades handled in the connector rather than in an emergency, monitoring on webhook delivery and queue depth, and the ERP kept as system of record throughout, so the storefront never quietly becomes a second source of truth. That pattern, embedded in Shopify, B2B-aware, both directions in real time, is what Uncap Connect is built to run, and building it as part of the migration is standard scope in Uncap's Magento migration practice, with the broader integration capability covered on the ERP integration page.

Uncap has been a Shopify Platinum Partner since 2013, with more than 380 B2B commerce projects delivered for manufacturers, distributors, and wholesalers. Talk to Our Experts if you want your current module's data flows walked against this architecture, that conversation is the start of the field mapping either way.