BigCommerce and Dynamics GP, built for the migration you already know is coming.

Worth stating plainly, because the summaries circulating in the GP community disagree with each other and at least one widely quoted date has already been revised.

If you are on GP 18.x, the current version under the Modern Lifecycle Policy:

• 31 December 2029. End of product enhancements, regulatory and tax updates, service packs and technical support. This was moved back from the originally announced 30 September 2029, so that customers could close a full payroll and tax year.
• 30 April 2031. End of security updates, and the end of subscription billing and SPLA usage.

If you are on an older build, under the Fixed Lifecycle Policy, the dates are much closer and two of them have passed:

• GP 2016 and 2016 R2: extended support ended 14 July 2026. That is behind us. If this is you, you are already out of support.
• GP 2018 and 2018 R2: extended support ends 11 January 2028.
• GP 2015 and earlier: long past end of support.

One detail that catches people: installing any current tax release or hotfix on GP 2018 moves you to 18.5 or later, which puts you on the Modern Lifecycle and buys you the 2029 and 2031 dates instead. There is no supported way to take those updates and stay on the fixed lifecycle.

Source: Microsoft's own Dynamics GP lifecycle documentation. If a partner quotes you a different date, check it there.

Three or more years is a long time in this business. A GP store that works, earns and serves a business whose shape has not changed does not need to be panicked into anything, and we will not pretend otherwise to sell a project.

But the storefront question is genuinely different from the ERP question, and it is the one people get wrong. If you integrate BigCommerce tightly to GP the way integrations were built in 2016, then when GP is replaced you do not migrate an ERP, you migrate an ERP and rebuild a storefront integration you paid for twice.

So the decision that matters now is not when to leave GP. It is how to build the seam. Done properly, the eventual move to Business Central, or to whatever you choose, touches one adapter and a test run. Done the usual way, it becomes a second project nobody budgeted.

That is the entire argument of this page, and it is worth more to you than it is to us, because it makes the work smaller.

BigCommerce is the straightforward end: documented REST and GraphQL APIs, webhooks, price lists and customer groups, with B2B Edition adding company accounts and hierarchies.

GP offers more routes than SAP does, and they differ sharply in how well they survive a migration:

• eConnect. The proper answer for writing into GP. Transactional, validated, and it respects GP's business logic rather than going around it. If orders are being created in GP, this is normally how.
• Direct SQL reads. Fast, easy, and legitimate for reading inventory, pricing and customer data. Convenient enough that people start writing with it too, which is where it stops being legitimate.
• Direct SQL writes. Do not. Skipping GP's business logic produces records that look right and behave wrong, and the damage typically surfaces at month end rather than at the moment you cause it.
• Web Services for Dynamics GP. SOAP era, still present in the field, rarely the right choice for a new build.
• SmartConnect and similar. eOne's tooling is genuinely widespread in the GP world and does a lot of the mapping and scheduling for you. Reasonable, and a real running cost, and worth knowing that it is another thing to migrate later.

The migration-aware view: eConnect and direct SQL are both GP-shaped, and neither concept exists in Business Central, which uses OData and AL extensions instead. So whichever you pick, the goal is to keep that choice contained in one place rather than letting it spread into the storefront.

The same six every B2B storefront asks of its ERP. Writing them down in your own words, rather than in GP's, is the single cheapest thing you can do today to make the eventual migration boring.

1. Who is this customer. The GP customer ID behind the login, plus ship-to addresses, which in GP are a separate concept people routinely forget to map.
2. What do they pay. Their price level, or their extended pricing sheet if you run that module. More on this below, because GP is genuinely easier here than SAP.
3. What can they have. Quantity available by site, not just quantity on hand, and allocated versus on-hand is a distinction that matters the moment two orders race.
4. Place the order. Into Sales Order Processing via eConnect, returning a real GP document number rather than a promise to sync later.
5. Where is it. Fulfilment and shipment status, with tracking where the carrier feeds it back.
6. What do they owe. Invoice history, open receivables and credit limit from Receivables Management. This is the part B2B buyers actually log in for, and it is consistently the last thing anybody scopes.

If you have read our BigCommerce and SAP page, the pricing section there is a warning. Here it is closer to a reassurance, and the difference is real rather than rhetorical.

Standard GP pricing is price levels: a customer is assigned one, and items carry prices per level per unit of measure. That is a lookup, not a calculation, and a lookup can be synchronised into BigCommerce price lists and customer groups with confidence. For a lot of GP businesses this is the whole story, and the integration is correspondingly cheaper than the SAP equivalent.

It stops being simple when Extended Pricing is switched on. That brings price sheets, date-effective pricing, quantity breaks and promotions, and it starts to resemble a calculation rather than a lookup. It is still far simpler than SAP's condition technique, but it is enough that exporting a flat price file will get the exceptions wrong.

The rule we work to:

• Standard price levels only? Sync them. Keep the sync frequent and event-driven, and reconcile on a schedule so drift gets caught rather than discovered by a customer.
• Extended Pricing, contract pricing or per-customer overrides? Ask GP at cart time and cache the answer, the same discipline the SAP page describes.
• Either way, no price means no add-to-cart. If GP holds no price for that customer and item, disable it rather than accepting an order that will fail downstream.

Worth knowing for later: Business Central's pricing model is closer to GP's than to SAP's, so a GP integration built cleanly around "get the price for this customer and item" ports across without a rethink.

This is the section to act on even if you hire nobody.

• Put an integration layer in the middle. The storefront talks to your layer. Your layer talks to GP. When the ERP changes underneath, you rewrite one adapter instead of a storefront.
• Define the six contracts in your own language. "Get price for customer and item" is a stable idea that will outlive GP. "Call this eConnect procedure" is not.
• Keep GP vocabulary out of the storefront. No customer IDs shaped like GP customer IDs, no document type codes, no site IDs leaking into your front-end code. Map at the boundary. This is nearly free now and expensive to retrofit.
• Log what the ERP returned, not just what you sent. When someone disputes a price in eighteen months, and they will, the question is what GP said at the moment they looked.
• Write the integration tests against the contracts. They then become your acceptance suite for the Business Central migration, which is the single biggest cost saver available on that project.

None of this is exotic and none of it is expensive at the time you build. All of it is expensive to add afterwards, which is why it is worth raising before anyone writes a proposal.

• Somebody wrote to GP with SQL. The most common serious problem in this category. It works in testing, and it produces records that reporting and month-end quietly disagree with.
• Orders duplicate. No idempotency key on submission, so a retry or a double click creates two Sales Order Processing documents, and nobody notices until fulfilment does.
• Inventory promises what it cannot ship. On-hand synced instead of available by site, so allocations are invisible to the store.
• Price drift. Price levels synced nightly, changed in GP at ten in the morning, and the store sells at yesterday's number until the next run.
• The integration is a scheduled task on somebody's desktop. More common than anyone admits in the GP world, and it stops the day that person's machine is replaced.
• GP-shaped assumptions in storefront code. Invisible until migration day, when it turns a one-adapter change into a rebuild.