01 / backbone
GP is the ledger
Finance, inventory, pricing, sales order processing. The authoritative record the business is actually run on, and it is running fine today.
Dynamics GP runs the business. The store runs the customer.
Microsoft Dynamics GP, formerly Great Plains, is where the ledger, the item master and the price cube live. Shopify Plus is where your buyer wants to be. The work is the space between, and on GP that space is wider than on any other ERP we integrate.
02 / front door
Shopify is self-serve
Where B2B buyers place repeat orders without a phone call, a rep, or a spreadsheet emailed to someone in customer service.
03 / the gap
The middle is where it breaks
Duplicate customers. Orders written twice. Pricing that drifts. Silent failures at month-end close, found by an accountant and not by a dashboard.
The GP twist
GP is the only sunsetting, on-premises ERP we integrate, and that changes the argument twice over. There is no cloud API, so there is no direct path: every transport terminates inside your LAN and a gateway is a structural requirement, not a preference. And Microsoft has published an end date, so the integration has to be portable. Middleware is not the better architecture here. It is the only one.
One direction for master data. Both directions for orders.
What syncs between Shopify and Dynamics GP: customers, price levels, items, and inventory are read out of GP and pushed to Shopify. The storefront never writes to your ledger. Orders are the only thing that travels both ways, and GP stays the source of truth.
Dynamics GP → Shopify Plus master data, one way
System of record · on-prem
Dynamics GP
SQL Server · eConnect · never overwritten
The platform
Makro Middleware.
on-prem agent + cloud core · map · reconcile · audit
The storefront
Shopify Plus B2B
where buyers self-serve
Master data: Dynamics GP → Makro Middleware → Shopify, one way
Orders: Shopify → eConnect → GP, status and tracking return
on-prem agent · MSMQOn-prem realities: queueing, retries and outage safety. Every GP transport terminates inside your network: SQL Server over TDS, MSMQ queues, WCF Windows services, AD-authenticated OData. There is no vendor-hosted public endpoint anywhere in the product, so a domain-joined Windows agent runs the eConnect assemblies in-process and connects outbound-only to the middleware. GP is never published to the internet. The eConnect Incoming Service over MSMQ is the vendor-provided durable buffer, so an order burst drains into GP at whatever rate SQL sustains, with no data loss.gateway
eConnecteConnect and GP Web Services on the ERP side: eConnect is the write path. XML documents that execute GP's own encrypted stored procedures, so business logic is enforced on insert rather than bypassed by a raw SQL write. One SOP engine covers everything, discriminated by SOPTYPE: 1 quote, 2 order, 3 invoice, 4 return, 5 back order, 6 fulfillment order. A single document can upsert the customer, upsert the items, and create the order atomically, with per-line ship-to overrides, drop-ship flags, serial and lot allocation, kits, and multicurrency.MK → GP
Web Services · OData v4Web Services for Dynamics GP is SOAP and WCF layered on eConnect; OData v4 is read-only. Web Services carries documented coverage gaps against eConnect: supplying your own taxes on sales orders, applying cash receipts, and POPTYPE=3 receivings cannot be done through it. OData, added in GP 2016 and updated in GP 2018 with paging and filtering, is reporting-grade and reads only. We build the write path on eConnect and use the read surfaces where they earn their place.GP → MK
direct SQL · delta readsCustomers, price levels and B2B pricing, inventory and item availability across GP sites. Watermarked delta reads against RM00101 for customers and their PRCLEVEL tier, IV00101 for items, IV00108 for the price cube, and IV00102 for quantity by LOCNCODE. SQL is also the only surface where every customization layer is reachable, which is why the Extender tables read here and nowhere else.GP → MK
Shopify Admin GraphQL APIShopify Admin GraphQL API and webhooks on the storefront side. New builds target the GraphQL Admin API, not REST, which has been legacy for new development since October 1, 2024. Governance is a cost-based leaky bucket at 1,000 points per second on Shopify Plus. Every inbound webhook is HMAC-verified and deduplicated on X-Shopify-Webhook-Id before it is trusted, because Shopify's own documentation is explicit that webhook delivery is not guaranteed and ordering within a topic is not guaranteed. Reconciliation is Shopify's documented requirement, not our flourish.MK ↕ Shopify
Transaction Requester · eConnect_OutReal-time versus batch: which entities need which. Order capture is real time and webhook-driven. Change capture out of GP is trigger-based: RequesterSetup adds SQL triggers that write to the eConnect_Out shadow table, and the Outgoing Service periodically queries that table before publishing XML to an MSMQ queue. That is polling, not push. The honest envelope: near-real-time into GP, minutes-scale out of GP. Fulfillment and tracking ride the same path out of SOP10107.GP → MK
This is not a connector. It is something you operate.
Every sync, every failure, every reconciliation is visible. This is the same Makro Middleware console your team would watch in production, on a demo tenant with a GP-shaped catalog. Move through the views.
console.makro.agency / halstead-industrial / sync
live
Sync Monitor
Sync Monitor
Dead Letter Queue
Observability
Entity Key Map
Schedules
Order Relations
Records / 24h ▲
48,210
across 9 entities
Queue depth
3 pending
2 retrying · 1 review
Avg latency
1.2s
webhook → eConnect
Last reconcile
04:00
0 drift detected
Activitylive · last 60s
Throughputrecords / hr
In queue
3
of 48,210 processed
Auto-retrying
2
transient · agent link
Needs review
1
permanent
Resolved / 24h
41
38 auto · 3 manual
Dead Letter Queuenothing is dropped in silence
| Time | Entity | Error class | Attempts | Next | Action |
|---|---|---|---|---|---|
| 08:13:04 | SOP order · WEB-0001038 | PERMANENT · eConnectException | 3 / 3 | held | Inspect |
| 07:55:22 | customer · RM00101 · CUST-00910 | TRANSIENT · agent link | 2 / 5 | 09:50 | Retry now |
| 06:40:11 | item qty · IV00102 · ITEM-44120 | RATE_LIMIT · paced | 1 / 5 | paced | Inspect |
Sync volume7-day · records
Circuit breakersper endpoint
GP · eConnect via agentlast trip · never
closedGP · SQL delta readslast trip · 6d ago
closedShopify · Admin GraphQLlast trip · 3d ago
closedUptime · 90 dayserror rate 0.03%
customer · Halstead West Yardentity_key_map
CUSTNMBRCUST004182
canonical uuid7c1e9a04-3b6f-4d21-…
shopify gidgid://shopify/Company/61…
checksuma91f… unchanged
versionv17
→ decision: SKIP · already in sync
Every record carries three identities at once: its GP key (CUSTNMBR, 15 characters), a canonical UUID the middleware owns, and its Shopify GID. The middleware reads this row before every write and decides create, update, or skip.
GP forces this. Its keys are short natural keys with no GUID at the API surface: CUSTNMBR 15, ITEMNMBR 30, SOPNUMBE 21. A Shopify GID does not fit in any of them, so the cross-reference map is ours to own. We stamp the GID into INTEGRATIONID for traceability and keep the join here.
Change detection runs on the stored checksum, so a catalog of 50,000 items with 12 real edits syncs 12 records, not 50,000.
Active schedules
7
all workflows enabled
Runs today
96
0 failures
Next run
09:46
IV00102 quantities
Nightly batch
01:00
full catalog · 48,210 records
Workflowstenant · halstead
Item delta syncSQL · IV00101 · watermarkedminutes-scale✓ 09:38 · 142 recordsdelta-drivenRun now
Inventory levelsIV00102 · QTYONHND − ATYALLOC per LOCNCODEminutes-scale✓ 09:41 · 3 SKUson changeRun now
Price cubeIV00108 → B2B catalogs and price listshourly✓ 09:00 · 1,204 rowsnext 10:00Run now
Customers & price levelsRM00101 · PRCLEVELminutes-scale✓ 09:40 · 6 recordsdelta-drivenRun now
Tracking returnSOP10107 · Requester → FulfillmentOrderson fulfillment✓ 09:42 · 11 orderson changeRun now
Posting-status sweepSOP10100 work vs SOP30200 historyevery 15 min✓ 09:30 · 4 batches opennext 09:45Run now
Daily reconciliationboth systems vs key mapdaily · 04:00✓ 04:00 · 0 driftnext 04:00Run now
Shopify order#1042
gidgid://shopify/Order/57…
companyHalstead West Yard
line 1ITEM-99320 × 12
line 2ITEM-44120 × 4
total$8,420.00
#1042↔WEB-0001042 · type 2✓
gid://Company/88…↔CUST004182✓
ITEM-99320 × 12↔99320 · qty 12✓
ITEM-44120 × 4↔44120 · qty 4✓
$8,420.00↔8,420.00 USD · DEFPRICING✓
entity key map · every id matched before write
GP sales documentWEB-0001042
SOPNUMBEWEB-0001042
SOPTYPE2 · order
CUSTNMBRCUST004182
line 199320 · qty 12
write statusin GP · SOP10100
posting statusbatch WEB-DAILY · unposted
Order journey#1042 → WEB-0001042 · write in 5s, posting tracked after
09:42:04webhook received→
09:42:04HMAC ✓ · dedup ✓→
09:42:05mapped · SOPNUMBE derived→
09:42:06agent · eConnect XML→
09:42:09WEB-0001042 created→
09:45:00posting status polled
drag, scroll, or use the tabs
Feature by feature.
Ten engineered subsystems sit between Dynamics GP and Shopify Plus. None of them is a setting you toggle. Each is something we built, and something your team can watch run.
01 / 10
Integrations are judged by how they fail. GP fails a lot more interestingly.
Follow one failed eConnect write. GP's error model is real and legible: an eConnectException carries a SQL procedure error code you resolve against taErrorCode in the system database, plus Node Identifier Parameters showing the offending values. Colour carries the verdict: amber is sorted, teal retries, red is held, green replays.
01
It arrives
An eConnect document is rejected, or the agent cannot reach SQL. Instead of disappearing into a Windows event log, it enters the pipeline and gets a verdict.
captured→ 02
It gets classified
Every failure is sorted before anything is retried, so a bad record never loops forever. The eConnectException error code is resolved against taErrorCode and the Node Identifier Parameters name the offending field, so the class is a fact and not a guess.
→ 03
Transient retries
A dropped agent link, a SQL timeout, or a Shopify 429 against the 1,000-point-per-second bucket backs off with exponential retry. Nothing is lost while it waits: inbound orders sit in the MSMQ queue.
→ 04
Permanent is held
A validation rejection routes straight to the dead-letter queue for review. This matters more on GP than anywhere else: eConnect does not roll back across documents, so a half-written import is a real state and compensation is the middleware's job, not the ERP's.
held for review→ 05
You replay it
Fix the cause, replay from the queue. The SOPNUMBE is derived deterministically from the Shopify order, so a replay collides on the key rather than writing a second order. A daily reconciliation pass catches anything the live path missed.
replayed · reconciledWhere off-the-shelf GP connectors break.
Dynamics GP to Shopify integrations break at predictable points. Every prebuilt connector and iPaaS template handles the happy path and skips these, because these are the parts that need a decision rather than a mapping.
The posting gap
eConnect creates transactions in work batches and cannot post them. There is no feature to programmatically post a batch in GP. So "order synced ✓" really means the order is sitting in an unposted batch in SOP10100 while GL, inventory relief and AR wait on a human.
→ posting status tracked as a first-class state, not write successThe inventory double-count
Available is On Hand minus Allocated, per LOCNCODE, out of IV00102. But a Shopify order not yet exported and allocated in GP is already in Shopify's committed. Push GP available naively and you oversell by exactly the in-flight amount.
→ publish on-hand and let Shopify net it, or publish available only once open orders are allocatedNo resolved price endpoint
No GP API returns the price a specific customer would actually pay. GetPricingByKey takes item, price level, currency and unit of measure: no customer, no quantity, no date. Price Trace Inquiry, the thing that does resolve, is a client window and not a service.
→ resolve from the synced cube for display, let GP re-price on ingest with DEFPRICINGExtended pricing
A company runs standard pricing or extended pricing, never both. Extended pricing's date-effective price sheets, price books and free-item promotions are not exposed by the read API at all. A template connector silently prices these merchants wrong.
→ SQL-level extraction plus order-time IncludePromo, scoped as its own workstreamThe Extender blind spot
GP's built-in user-defined fields auto-flow: customer USERDEF1 and USERDEF2, item USCATVLS_1 to 6 are first-class eConnect elements. Extender data does not. It lives in EXT00100, not on the host record, so it is absent inbound and outbound, and Web Services never auto-flows a custom field at all.
→ read over SQL, write through custom eConnect nodes in the same transactionReplay duplicates
eConnect has no idempotency-key mechanism. Nothing in the schema reference provides a dedupe token, and eConnect does not roll back across documents. Replay a create with a fresh document number and you get a second order in the ledger.
→ deterministic SOPNUMBE, so a replay collides instead of duplicatingWhat you will hear, and what the docs actually say.
Every reality below is verified against a primary Microsoft or Shopify source, or a named vendor document. Four of them rest on what the documentation does not contain, which is exactly the point being made. This is the difference between a team that read the marketing and a team that shipped against the documentation.
01
The claim"Dynamics GP has a modern API. Point your integration at it."
The realityGP has no modern REST API and no vendor REST write surface at all. The documented surface is Windows-era: eConnect, Web Services for Dynamics GP, Integration Manager, direct SQL, and a read-only OData v4 feed added in GP 2016. There are no webhooks and no eventing. The eConnect reference documentation was last updated May 2014 and lives in Microsoft's archived previous-versions tree.
02
The claim"Your cloud store can just connect straight to GP."
The realityThere is no endpoint to connect to. Every GP transport terminates inside your LAN: SQL Server over TDS, MSMQ queues, WCF Windows services, AD-authenticated OData. A Shopify integration requires an on-premises agent or a private tunnel. The market concedes it: eOne's GP connection is available only in the on-premises SmartConnect product, and Commercient's cloud service installs "an integration agent installed on the ERP side."
03
The claim"We will authenticate the integration with an API key, same as any SaaS."
The realityNothing in GP speaks OAuth 2.0, and no API key exists. GP's perimeter is Windows Integrated Authentication and SQL Server logins; Shopify's is token-based HTTPS. Microsoft is explicit that a GP user's own credentials do not work from outside GP: "the attempt to log in will be denied because the passwords will not match." The middleware is the mandatory trust boundary.
04
The claim"GP is still supported, so nothing is changing."
The realityNothing is changing until it does, and Microsoft has published the date. Product support, enhancements, regulatory tax updates and technical support end December 31, 2029. Security updates run only until April 30, 2031. Microsoft's own words on the destination: "We are encouraging customers to transition to Dynamics 365 Business Central." GP is genuinely fine to run today and still takes three all-inclusive updates a year under the Modern Lifecycle Policy. But after 2029 there are no tax or regulatory updates, and no Microsoft support if an integration-critical process breaks.
05
The claim"If there is a bug in eConnect, Microsoft will fix it."
The realityMicrosoft has said in its own current documentation that it will not. Verbatim: "Microsoft is not actively fixing these issues in the eConnect shipping product, due to the life cycle of the product." It publishes a short list of modified stored procedures as-is instead, and warns that "Custom procedures might be lost during an upgrade." The core procedures are encrypted, so you cannot fix them either. This is precisely why integration logic belongs outside GP.
06
The claim"Microsoft partnered with Shopify, so there is a first-party connector."
The realityThere is, and it is not for GP. Business Central ships a genuine first-party Shopify connector, preinstalled for new sign-ups. No equivalent exists for Dynamics GP: nothing in the GP documentation set offers a native Shopify connector, and every GP to Shopify connection on the market is third-party. The first-party connector a GP merchant eventually inherits lives on the Business Central side. That asymmetry is itself the bridge argument.
07
The claim"The connector said the order synced, so the order is in GP."
The realityThe order is in GP. It is not in your ledger. eConnect creates transactions in work batches and cannot post them: GP has no feature to programmatically post batches, so posting stays a client operation. Every "order synced ✓" really means "the order is sitting in an unposted batch in SOP10100," while GL, inventory relief and AR wait on a human. Posting status is a first-class reconciliation concern, not a footnote.
08
The claim"GP calculates your cart tax."
The realityIt cannot, and you would not want it to. There is no synchronous tax surface anywhere in GP's toolset: it is built for document creation, not sub-second rate quoting in a checkout. The native engine intersects manually maintained tax schedules by shipping method, and Microsoft documents the failure plainly: "If the line item is not assigned a shipping method, no taxes will automatically be calculated for the line item." Cart-time tax runs in Shopify and GP records it.
09
The claim"Sync GP's available quantity to Shopify and you're done."
The realityThe equation is right and the naive push is wrong. Microsoft's arithmetic: "On hand quantity − quantity available = quantity allocated," so Available is On Hand minus Allocated per LOCNCODE from IV00102. The trap is double-counting: an order not yet exported and allocated is already in Shopify's committed, so GP available is too high by the in-flight amount. Two more traps: GP kits have no sellable quantity of their own, and IV00102 is documented as corruptible into negative allocated quantities.
10
The claim"Just read the customer's price out of GP at checkout."
The realityNo GP API returns a resolved customer-specific price. GetPricingByKey takes item, price level, currency and unit of measure. Note what is absent: no customer, no quantity, no date. The caller must already know the price level and re-implement GP's own defaulting hierarchy plus the quantity bands. Price Trace Inquiry, the one thing that truly resolves, is a client window and not a service. The engine only runs while a document is being inserted.
11
The claim"The connector handles B2B customer pricing out of the box."
The realityGP's pricing is a cube, not a rule engine, which is good news structurally and bad news for template connectors. Every IV00108 row is keyed by item × currency × price level × unit of measure × quantity band, and the customer's tier is a single PRCLEVEL field on RM00101. That maps unusually cleanly onto Shopify B2B, but it is explicit mapping work per merchant. Standard pricing has no per-customer price lists and no effective dates. Discovery question one on every GP deal: standard or extended?
12
The claim"It's real-time, two-way sync."
The realityNot on this stack, and any page claiming it is overpromising. Into GP is near-real-time and webhook-driven. Out of GP is minutes-scale by construction, because the mechanism is polling: RequesterSetup adds SQL triggers writing to eConnect_Out, and the Outgoing Service "periodically queries the eConnect_Out table" before publishing to MSMQ. Meanwhile Shopify's own docs say webhook delivery is not guaranteed and "For redundancy, use reconciliation jobs."
Three ways to connect Dynamics GP and Shopify.
Custom middleware vs a prebuilt connector is the question everyone asks, and the framing is usually wrong. All three routes below write through eConnect. Even SmartConnect converts its destination into eConnect XML. The choice is not about the write path. It is about who owns the mapping, the recovery, and the code.
Option 01
Prebuilt GP connector
A packaged product with fixed field mappings over eConnect. Fast to stand up, and rigid by design.
- mappingsfixed
- recoveryper-record error queue
- customizationsnode purchase, or unsupported
- 2029a rebuild
Right for vanilla GP installs with standard fields, standard pricing, and no ISV modules in the order path.
Option 02
iPaaS subscription
Flexible tooling on a shared platform, with a permanent fee. You still configure the GP side, and the agent still lives on your LAN.
- mappingstemplate-bound
- tenancyshared platform
- pricingannual fee, forever
- GP reachon-premises product only
Right for standard multi-system sync where the B2B logic fits a fixed-mapping template and the meter is acceptable.
Option 03 · our build
Custom middleware
Built on eConnect around your exact order flow, pricing engine and customizations. Owned by you, operated with a support agreement.
- mappingsyour fields
- tenancysingle-tenant
- recoveryDLQ + replay + posting status
- 2029an adapter swap
Right for customized GP environments: B2B price levels into Shopify catalogs, extended pricing, multi-company, Extender and ISV tables, and any merchant who intends to still be selling after the migration.
Timeline by scope, not a contact-us wall.
Timeline and pricing on GP are driven by two answers we get in the first week: standard pricing or extended, and one company database or several. A build lands in one of three bands. We do not publish week counts we have not earned on a GP install.
Band 01 · foundation
01
single company · standard pricing · vanilla items
- Customers, items and inventory one way out of RM00101, IV00101 and IV00102
- Orders both ways through eConnect, with a deterministic SOPNUMBE
- Available published as On Hand minus Allocated, per site
- On-prem agent, MSMQ buffer, dead-letter queue and daily reconciliation
- Posting status tracked from day one
Band 02 · B2B
02
Shopify Plus B2B · the price cube
- Everything in foundation
- IV00108 flattened into Shopify B2B catalogs and price lists
- Quantity bands mapped to Shopify quantity breaks
- PRCLEVEL tiers mapped to company profiles, credit limits and terms
- Cart tax in Shopify, booked into GP with CREATETAXES=0 and line tax nodes
Band 03 · multi-entity + customization
03
multi-company routing · extended pricing · ISV tables
- Everything in B2B
- Entity routing across one SQL database per company
- Extended pricing: price sheets, price books and promotions over SQL, IncludePromo on ingest
- Extender and ISV tables read over SQL, written through custom eConnect nodes in the same transaction
- Kits derived from component availability
Cost · scoped per build
We price a Dynamics GP integration as an engineering engagement: a build with a support agreement, not a per-record meter or a platform seat that renews forever. For context, enterprise iPaaS commonly runs $30,000 to $100,000+ a year before the work begins. That is the market's number, not ours. Ours comes out of your discovery, and we will not quote a band before we have seen your pricing engine.
Built to pass your IT review, and your GP administrator's questions.
GP has no modern credential to give Shopify, and Shopify has no Windows identity to give GP. The middleware is the mandatory trust boundary, and neither credential ever crosses it.
The trust boundary
The agent initiates every connection outbound to the middleware over TLS. No GP endpoint is published to the internet, no inbound firewall rule, no VPN into the ERP network. This is the same shape the working commercial connectors use, because the surface leaves no other option.
Least privilege on GP
One dedicated non-interactive domain account, for example svc-econnect-shopify, vaulted and never shared with a human. Its SQL login joins DYNGRP only on the in-scope company databases. Never sysadmin, never domain admin. Reads use narrow GRANT SELECT where possible; writes go through eConnect procedures only. TLS is forced on the SQL connection, because GP encrypts only the pre-login exchange by default.
Inbound traffic is verified
Every Shopify webhook is HMAC-verified against X-Shopify-Hmac-SHA256 before it is trusted, then deduplicated on X-Shopify-Webhook-Id. The admin token is offline-mode with least-privilege scopes, held in a secrets manager and never in job config. Shopify tokens cannot be rotated in place, so a rotation runbook ships with the build.
Everything is on the record
Credentials are encrypted fields, isolated per tenant, rotatable without downtime, and never in plaintext. An append-only, source-tagged audit trail logs every operation, so you can prove what happened during month-end close, including which documents were written and which batches were still open.
Where Dynamics GP integrations get hard, and where we land.
The details that separate a team that read the docs from a team that shipped against them.
01Can Shopify integrate with Microsoft Dynamics GP?+
Yes. Dynamics GP has no native Shopify connector, but the two systems integrate reliably through GP's eConnect API or Web Services on one side and Shopify's Admin API and webhooks on the other. Orders, inventory, customers, fulfillment, and pricing can all sync bidirectionally, either through a prebuilt connector, an iPaaS platform, or a custom-built integration.
02How do Shopify orders get into Dynamics GP?+
When an order is placed, a Shopify webhook fires in real time. The integration layer validates and maps the payload, including line items, discounts, tax, shipping, and payment reference, then writes a Sales Order Processing document into GP via eConnect, which enforces GP's business logic on insert. Fulfillment and tracking numbers flow back to Shopify the same way.
03Is Dynamics GP to Shopify inventory sync real time?+
Order capture is real time and webhook-driven. Inventory sync from GP is near-real-time: GP quantity changes are detected on triggers or short polling intervals and pushed to Shopify inventory levels. True latency depends on where GP runs and the bridge architecture; a well-built integration keeps the storefront within minutes of GP stock.
04Should I use a prebuilt connector, an iPaaS, or a custom integration?+
Prebuilt connectors suit vanilla GP installs with standard fields. iPaaS platforms add flexibility but carry permanent subscription fees and still require GP-side configuration. Custom integrations built on eConnect fit customized GP environments, including B2B pricing, multi-company, and ISV modules, and you own the code with no per-order fees. The more customized your GP install, the more the custom route wins.
05Dynamics GP support ends in 2029. Is integrating with Shopify still worth it?+
Usually yes. GP support ends December 31, 2029, with security updates to April 2031, and an ERP migration takes 9 to 18 months, but ecommerce revenue cannot wait for it. The right architecture integrates Shopify to GP now through a middleware layer that isolates GP-specific logic, so the same flows re-point to Dynamics 365 Business Central later without rebuilding the store.
06Can Shopify B2B use Dynamics GP customer-specific pricing?+
Yes, but not with most off-the-shelf connectors. GP customer price lists, credit limits, and payment terms can be mapped into Shopify B2B company profiles, catalogs, and payment terms. This is custom mapping work, and it is the most common reason wholesale merchants outgrow standard GP to Shopify connectors.
07Does it work with on-premises Dynamics GP behind a firewall?+
Yes, and it has to be designed for it. GP has no cloud endpoint: every surface, including SQL Server, eConnect, and Web Services, terminates inside your network. The integration runs an on-premises agent that connects outbound only, so GP is never exposed to the internet. Orders queue durably and replay if the GP server or the link goes down.
08What happens to the integration when we migrate off GP?+
The Shopify side does not get rebuilt. The middleware holds the mapping, orchestration, and storefront contracts, and speaks to GP through a swappable ERP adapter. When you move to Dynamics 365 Business Central, the adapter is replaced and the storefront, the data contracts, and the operational tooling carry over.
09Can it support multiple GP companies feeding one Shopify Plus store?+
Yes, with an entity-routing layer in the middleware. GP is architected as one database per company, so items, customers, price levels, and the whole price cube live per entity and are not shared. The middleware routes each order to the right company database and merges the catalogs and availability the storefront sees.
One platform. Your ERP is an adapter, not a rebuild.
Every ERP sits behind the same contract: connect, fetch companies, fetch products, fetch inventory, create the order. The sync engine, mapping layer, error handling and Shopify integration never change when a new system plugs in.
GP support ends in 2029. Integrate now, or migrate first? That is the question the VAR answers with "wait" and the connector vendor does not answer at all. It is the wrong question. A migration runs 9 to 18 months from decision to go-live and ecommerce revenue cannot wait for it, so the real question is whether the storefront survives the move.
The store integrates to the middleware, not to GP. A packaged connector is a rebuild in 2029. A middleware layer is an adapter swap.
adapter contractbase.ts
01connect()Windows account · SQL login
02fetchCompanies()RM00101 · per company DB
03fetchProducts()IV00101 · IV00108 cube
04fetchInventory()IV00102 · per LOCNCODE
05createOrder()eConnect · idempotent
NS
NetSuite
SuiteQL · token auth · saved search
GP
Dynamics GP
eConnect · on-prem agent · SQL reads
D3
Dynamics 365 F&O
OData · custom fields · Entra ID
BC
Business Central · Sage · Infor · Epicor
REST / OData adapters
Today, the GP adapter: eConnect XML and SQL, through a domain-joined on-prem agent.
Later, the Business Central adapter: OData v4 and Entra ID, over the public internet. The agent disappears.
What does not change: the canonical model, the entity key map, the Shopify contracts, the field mappings, the dead-letter queue, the reconciliation, and the storefront.
Claims you can check.
Read this part carefully, because it is where most pages cheat. We have no Dynamics GP deployment to point at. The outcome below is a NetSuite build. It is here as pattern proof that we integrate Shopify Plus with enterprise ERPs and take manual entry out of the middle, and for no other reason. The five numbers beside it are platform claims about the middleware itself, counted in the repository, not telemetry from a GP install.
$100K+ / yr
Clarius · a NetSuite outcome, not a GP oneWe built a unified account page integrating Clarius' NetSuite ERP, Salesforce CRM and Shopify Plus into a single view of customer information, orders and invoices across three enterprise systems. Combined with Shopify Flow automation feeding order data into NetSuite, it eliminated manual order entry and reduced operational costs by over $100,000 a year. Different ERP, same pattern: the store integrates to the layer, and nobody re-keys an order.
1,756
Automated tests across 139 suites, run on every change.
85%
Coverage gate enforced before any deploy.
39
End-to-end browser tests across Chromium, Firefox and WebKit.
7
Failure classes, each with its own pre-decided policy.
0
Credentials stored in plaintext, anywhere, ever.
Bring your GP administrator and your connector quote. We will walk the platform, not a deck.
A real conversation about your GP install, your pricing engine, and what happens to the storefront when you move to Business Central.