---
title: "Dynamics GP to Shopify Integration"
url: https://www.uncap.com/integration/dynamics-gp
author: "Denis Dyli"
published: 2026-09-27
updated: 2026-09-27
summary: "Great Plains has been running distribution and manufacturing businesses in North America for decades, and a lot of them are still on it because it works and because replacing an ERP is a genuinely disruptive thing to do. New customer sales stopped on 1 April 2026. End of support is 31 December 2029. Security updates and patches remain available, if needed, until 30 April 2031."
---

# Dynamics GP to Shopify Integration

> Great Plains has been running distribution and manufacturing businesses in North America for decades, and a lot of them are still on it because it works and because replacing an ERP is a genuinely disruptive thing to do. New customer sales stopped on 1 April 2026. End of support is 31 December 2029. Security updates and patches remain available, if needed, until 30 April 2031.

It is also a product with published end dates, and one of them has already passed. If you are weighing an ecommerce project on GP, those dates are the first input, so here they are before anything else.

## The dates, exactly

**New customer sales stopped on 1 April 2026.** Microsoft set that as the final day for new customers to license Dynamics GP subscriptions. That date is in the past.

**End of support is 31 December 2029.** Microsoft moved this from a previously announced 30 September 2029. After that date there are no product enhancements, no regulatory or tax updates and no technical support.

**Security updates and patches remain available, if needed, until 30 April 2031.** On that same date, additional perpetual users can no longer be added to existing systems.

If you are on an older release rather than GP 18.x, your date is sooner. GP 2016 and 2016 R2 extended support ends **14 July 2026**, which is close. GP 2018 and 2018 R2 ends **11 January 2028**. GP 18.x sits on the Modern Lifecycle Policy with the 2029 and 2031 dates above.

Nobody competing for this term publishes that timeline. Several gesture at 2029. The dates are on Microsoft's own pages and they are not hard to find, which makes the omission a choice.

## What those dates actually mean for an ecommerce project

The instinct is to conclude that you should replace the ERP before building anything. We tested that instinct twice with a web-connected model, same prompt, and both runs said the opposite.

The repeated advice was to integrate GP now rather than wait for an ERP replacement, unless a replacement is already funded and underway. Both runs put a GP integration at roughly four to nine months and an ERP-replacement-first path at twelve to twenty-four, and both named doing the two at once as the highest-risk option of the three.

That matches what the arithmetic says. Build a storefront on GP in 2026 and it has three years of normal operation before end of support and five before security updates stop. Wait for a replacement and you have a channel you do not have, during the years you could have been selling through it.

Both runs also named the same mitigation, and it is the right one. Keep the integration thin. GP stays the system of record; it does not become the system of experience. No business logic gets embedded in GP for the storefront's benefit. The connector is the replaceable part, and the storefront, catalog and customer structure outlive the ERP underneath them.

That is a design instruction, not a slogan, and it is the thing to hold any proposal against.

## What GP exposes

Microsoft documents several mechanisms and the preference order is worth knowing because it is not the one most people assume.

**Web Services** is what Microsoft calls the preferred tool for integrating data, with eConnect used when the objects you need are not available there.

**eConnect** is the workhorse most GP integrations actually run on. Microsoft describes it as giving fast access to the back office of transactions through COM-based or .NET-based API adapters, built on stored procedures, triggers and custom tables with XML documentation. It is mature, it is well documented and it enforces GP's business rules rather than writing around them.

**Integration Manager** handles bulk and scheduled movement without custom programming. **Visual Studio Tools for GP** is the route for genuine extensions.

**Dexterity** is the original customization layer. Treat it as legacy and as something that may exist in your environment rather than as an integration path for new work. Microsoft's current documentation for it sits in the troubleshooting namespace, which tells you where it stands.

The practical shape of all this is that GP is on-premises on SQL Server, so something has to run where it can reach that server. That component is part of the build, and it needs somewhere to live and someone to operate it.

## Where the two systems line up

GP customers become Shopify companies, with ship-to addresses as company locations and contacts as buyer logins, so each buyer signs into the account they are authorized to buy for.

Pricing comes from wherever your GP is configured to hold it, and GP offers two models. Standard pricing uses price levels, with the price level held against the customer in Customer Maintenance. Extended pricing uses price sheets and price books instead. Which one you run changes the integration, and it is an early question rather than a late one.

Items become products with their attributes and units of measure. Inventory comes by site, because a distributor with several sites needs the storefront to show the one that will ship.

A Shopify order becomes a GP sales order through Sales Order Processing, which handles quotes, orders, invoices, back orders and returns, with the document type and the customer reference set correctly so it lands where your team expects it.

[Uncap Connect](https://www.uncap.com/products/connect) keeps pricing, inventory, customer data and orders current in both directions, built for B2B so customer-specific pricing, credit terms and tax behave the way they do in your business.

## What happens when an order fails

GP being on-premises changes the failure profile in the same way it does on any self-hosted ERP. The connection has maintenance windows and occasional bad afternoons, so orders queue rather than disappear.

Transient failures, including the server simply being unavailable, retry on a backoff. Permanent failures, such as an inactive item or a customer over their limit, hold with the payload and the exact GP error preserved, somewhere your team already looks, and replay without asking the customer to reorder. Replay has to be idempotent, because a retry that creates a second sales order is worse than the original failure.

The buyer's Shopify order stays visible to them throughout.

## What we build

A thin, isolated GP connector, because the integration should be the replaceable part when the ERP is eventually replaced.

Company accounts, company locations and buyer logins mapped from the GP customer structure.

Price resolution appropriate to whether you run standard or extended pricing, with the logged-in account getting the number GP would actually invoice.

Inventory by site, with the allocation logic your operation uses.

Order creation through the documented mechanism, meaning Web Services where the objects exist and eConnect where they do not, with a queue, a held-order path and idempotent replay.

A storefront, catalog and customer experience built to survive the ERP migration you will eventually do.

## Industries that run Dynamics GP

[Industrial Supply and MRO](https://www.uncap.com/industry/industrial-supply-mro), where catalogs run past a hundred thousand items and procurement buys through its own systems.

[Construction Supply](https://www.uncap.com/industry/construction-supply), where will call and job accounts decide whether the site gets used.

[Packaging and Shipping Supplies](https://www.uncap.com/industry/packaging-shipping-supplies), where each, case and pallet pricing has to resolve correctly for every account.

GP is one of four Dynamics products we connect to Shopify. The [Microsoft Dynamics integration overview](https://www.uncap.com/integration/microsoft-dynamics) covers Business Central, Finance and Operations, and NAV.

## Ready to talk

Bring your GP version, whether you run standard or extended pricing, and whether an ERP replacement is funded. That last answer changes what we would recommend building more than anything else on the list.

Book a strategy session, or start with a [Blueprint](https://www.uncap.com/blueprint), the paid discovery engagement that maps the integration surface, the pricing model and the phased plan before development begins.

## Frequently asked questions

### When does Dynamics GP support actually end?

End of support is 31 December 2029, moved from a previously announced 30 September 2029. After that there are no enhancements, no regulatory or tax updates and no technical support. Security updates and patches remain available, if needed, until 30 April 2031, which is also the date after which additional perpetual users can no longer be added. New customer sales stopped on 1 April 2026.

### Is it worth integrating GP if it is end of life?

Usually yes, and that is the repeated answer from testing the question rather than our sales position. A storefront built on GP now has roughly three years before end of support and five before security updates stop. Replacing the ERP first typically takes twelve to twenty-four months, during which you do not have the channel. The exception is when a replacement is already funded and underway.

### Should we replace the ERP and build the storefront at the same time?

That is the highest-risk path of the three and both prompt runs named it as such. Doing them sequentially, with a thin integration built first, gets you the revenue channel earlier and leaves the harder project unentangled.

### How does GP connect to Shopify?

Through documented Microsoft mechanisms. Web Services is what Microsoft calls the preferred tool for integrating data, with eConnect used where the objects are not available there. eConnect gives access to back office transactions through COM-based or .NET-based API adapters built on stored procedures, triggers and custom tables. Integration Manager handles bulk movement, and Visual Studio Tools for GP handles genuine extensions. There is no native Shopify connector for GP.

### What about Dexterity?

Treat it as a legacy customization layer that may exist in your environment rather than as an integration path for new work. Microsoft's current documentation for it sits in the troubleshooting namespace. If your GP has Dexterity customizations, they matter for discovery, because they are often where undocumented business rules live.

### Which GP pricing model do we have?

One of two, and it changes the integration. Standard pricing uses price levels, with the customer's price level set in Customer Maintenance. Extended pricing uses price sheets and price books. Establishing which you run is an early question and it is worth checking rather than assuming.

### What happens to the storefront when we eventually migrate off GP?

That depends entirely on how the integration was built, which is why the design principle matters. Keep GP as the system of record rather than the system of experience, keep the ERP-specific work thin and isolated, and embed no storefront logic in GP. Done that way, migration replaces the connector and leaves the storefront, catalog and customer structure standing.

### Does our GP version matter?

Yes, and older versions have nearer dates. GP 2016 and 2016 R2 extended support ends 14 July 2026. GP 2018 and 2018 R2 ends 11 January 2028. GP 18.x runs on the Modern Lifecycle Policy with the 2029 and 2031 dates. If you are on an older release, upgrading within GP may be the cheaper first move.