BigCommerce with Business Central, where the ERP updates whether you are ready or not.

Nearly every wrong statement about Business Central support comes from answering for one deployment and meaning the other. They are genuinely different, so start by saying which you are.

Business Central online has no published end-of-support date. Its Microsoft lifecycle page carries only a start date and a retirement date, and the retirement date reads "In Support". There are no mainstream or extended end columns on that page at all, which is the structural difference from the NAV and GP pages where those columns are the whole story. It sits under the Modern Lifecycle Policy, which keeps a product supported for as long as you stay current, stay licensed, and Microsoft still offers it.

Business Central on-premises is dated, version by version. This is the part partner summaries get wrong most often. Right now only three on-premises versions are in support:

• v26.x runs out on 13 October 2026. That is about seven weeks away and it is the nearest live date on this page.
• v27.x runs out on 5 April 2027.
• v28.x, the current release, runs out on 12 October 2027.

Everything below those is already out. Thirteen on-premises versions have passed their end date, including the whole v15 to v25 run and the older v13 and v14 releases listed under the fixed policy.

The reason for the split is worth understanding rather than memorising. Microsoft can update the online service itself, so it does not need to date it. On-premises it cannot, because you control when you install. So it dates each version instead.

Check any of it on Microsoft's lifecycle product pages. If someone quotes you a different figure, that is where to settle it.

Business Central online takes a major update every April and October, plus minor updates in most other months. The current release is version 28.x, which went out on 1 April 2026.

You can defer, but only within a window, and the shape of that window is the thing most integrations are not built for:

• An update period of five months, inside which an admin can reschedule to any date.
• A one-month grace period after that, each September and each March, during which you can no longer push the date out further.
• Then an enforced update period. In Microsoft's own words, extensions that cause the update to fail "might be automatically uninstalled from the environment so that the update succeeds". Their data is not deleted and comes back when you install a compatible version, but the extension itself is removed to clear the way.

Read that last point as an integrator rather than an administrator. If your storefront depends on a per-tenant extension, and that extension does not compile against the next major version in time, the platform's response is to remove your extension rather than to hold the tenant back. There is no version to sit on and no support contract that buys you out of it.

So the question stops being when you have to move. It becomes whether your integration can survive an April and an October, every year, indefinitely. That is a testing and ownership question, and it is the one that actually decides the cost of running a storefront on Business Central.

On NAV, on AX and on GP, the shortcut is always the same: read the tables directly. Our pages on those three spend most of their length arguing against it. On Business Central online the argument is over, because the door is not there.

Microsoft is unusually blunt about it. For Business Central online, the only supported way to read data is through APIs. Direct database access does not exist as an option, and Microsoft explicitly warns that building an on-premises integration that depends on it will block you from moving online later.

That retires a lot of things quietly at once. Every ODBC pull. Every reporting job against a read replica. Every nightly SELECT a storefront grew to depend on. Every eConnect-shaped stored procedure, if you are arriving from GP.

We think this is the best thing about the platform from an integration standpoint, and it is worth saying plainly because it sounds like a restriction. Being forced through a published contract is exactly the design the other three pages have to talk people into. Here you get it whether you wanted it or not, and the class of failure where an upgrade silently changes a table under a working integration simply does not arise.

There are three web service types and they are not equal. Two of them have a removal date attached to a common pattern.

• The standard REST API, v2.0. Still the current version, with no v3.0 documented. Good for the common entities, and it needs no publishing step. It does not cover everything, and one gap matters enough that it has its own section below.
• Custom API pages, written in AL and shipped in a per-tenant extension. The right answer for anything the standard API does not cover. They cannot render in the interface, which is the point: they exist to be a stable integration surface rather than a screen someone might redesign.
• OData v4 on ordinary pages and queries. Works, but each endpoint has to be registered by hand on the Web Services page and ticked as published, which makes your integration depend on tenant configuration somebody can switch off.
• SOAP. Deprecated. The protocol itself has no announced removal version, so treat anyone who gives you one as guessing.

The two dates. Exposing a page that Microsoft published, meaning anything from the Base Application or the first-party apps, is going away as an endpoint:

• As a SOAP endpoint, removed in version 29.0, which is 2026 release wave 2.
• As an OData endpoint, removed in version 30.0.

If your storefront reads standard Business Central pages as web services, those are two hard deadlines about a year apart, and they are far more likely to affect you than anything on the lifecycle page. The fix is the same in both cases and is worth doing once: move to a custom API page inside your own extension. Microsoft's own guidance says the same thing for its own reasons, which is that a standard interface page returns things you do not want and prepares things you never asked for, and the developer who changes it has no idea you were reading it.

Webhooks exist and work on API pages. Business events are the newer and more interesting mechanism, but they are still documented as preview, so we would not put a storefront's order flow on them yet.

The same six every B2B storefront asks of its ERP. On Business Central the platform has already forced the contract on you, so the only remaining question is whether the contract speaks your language or Microsoft's.

1. Who is this customer. The customer account behind the login, plus ship-to addresses. Note that pricing resolves against the bill-to customer, which is not always the person logged in.
2. What do they pay. The hard one on this platform. See below.
3. What can they have. Availability by location, net of reservations, not just quantity on hand.
4. Place the order. Returning the real Business Central document number, not a storefront id with a promise to reconcile later.
5. Where is it. Shipment and posting status, with tracking where the carrier provides it.
6. What do they owe. Posted invoices, open entries and credit position. Still the thing B2B buyers log in for, and still the thing that gets scoped last.

Write those six in your own vocabulary and keep the Business Central specifics behind them. It costs nothing today and it is what makes the twice-yearly update a test run rather than a project.

Across these four pages, pricing is what really decides the cost of an integration. Business Central looks like it should be the easy one and it is not. It lands nearer SAP, where the ERP has to calculate, than GP, where a price level often syncs cleanly.

Two facts drive that, and the second is the one nobody expects.

The standard API exposes no pricing entity at all. There is no endpoint in API v2.0 that will hand you a resolved price. Live pricing needs a custom API page or a codeunit that calls the price calculation directly.

Microsoft's own e-commerce connector does not export prices, it calculates them. Faced with exactly this question for its Shopify connector, Microsoft chose to create a temporary sales quote for the item and run standard price calculation logic against it. It is also candid about the limitation of the export approach: that connector cannot export prices or discounts that vary by quantity. When the vendor's own team looked at export versus calculate for a real storefront, they picked calculate.

The rules underneath are individually small and collectively defeat naive code. Lowest price is scoped per currency rather than globally. A price group can suppress a lower price on the item card. Unit of measure matching is inclusive, so a row with a blank unit competes as a wildcard. The agreement is tested against the bill-to customer, not the shopper. Orders resolve on order date while invoices resolve on posting date. And a winning price row carrying "Allow Line Disc." switched off will legitimately cancel the discount your cart was about to apply, which is precisely the mistake a storefront makes when it computes best price and best discount separately.

So the practical rule:

• You may sync a resolved projection, one catalogue per pricing profile, but only where quantity breaks are absent or enumerable, campaigns are not in play, and you know the bill-to account and the document date when you build it. Segment on currency and on whether prices include VAT, or you will mis-price a VAT-inclusive storefront.
• Cart and checkout should ask Business Central, because the moment any of those conditions fails, and quantity breaks alone are enough to fail them, a projected price is a guess.
• No price means no add to cart. Disable it rather than accepting an order that fails on posting.

One more thing to keep an eye on. The newer sales pricing experience is still optional today, but Microsoft has already signposted it once for mandation and then slipped the date. Treat it as a live risk on the roadmap rather than a settled question, and know which experience your tenant is actually running before anyone quotes the work.

On NAV and GP the storefront could behave like a database peer. On Business Central online it is an API client with published limits, and the limits are lower than people assume because they are metered per user rather than per environment.

• 6,000 requests per five-minute sliding window, per user. Over that you get an HTTP 429. If you have seen 600 per minute quoted, that is the older per-environment figure and it has been superseded.
• Five concurrent requests per user, with a further 95 queued and 100 connections maximum.

The concurrency number is the one that bites. A storefront calling Business Central live on every product view hits the five-concurrent wall long before it approaches the request ceiling, and the failure does not present as a clean 429. It presents as requests sitting in the queue, page renders hanging, and eventually a 503. It happens during a traffic spike, which is to say during the exact minutes that mattered commercially.

Two consequences worth designing around. First, Microsoft's advice for throttling is to queue the request and retry later, which is available to a nightly job and unavailable to a page render, so the storefront has to cache rather than retry. Second, if you do need real headroom, Microsoft's own scaling guidance for an e-commerce portal is to spread the load across several application identities, because the limit is per user.

One correction to a common piece of advice: Microsoft documents a retry-after header on 502 and 503 responses and pointedly does not document it for 429. Do not build your backoff assuming it is there without checking against your own tenant.

Which is the whole argument for the split we recommend everywhere: catalogue and search served from cached data, cart and checkout asking the ERP.

• The integration reads standard Microsoft pages as web services. It works today and it has a removal date, version 29.0 for SOAP and 30.0 for OData. This is the most common thing we expect to find on existing builds.
• Prices were exported rather than calculated. Fine until a quantity break, a campaign or a bill-to that differs from the shopper, then confidently wrong in a way nobody catches until an invoice is disputed.
• The storefront calls the ERP on every page view. Passes testing at low traffic, queues and times out on the day the promotion lands.
• A per-tenant extension nobody owns. It compiles today. It does not compile against the next major version, and the platform's remedy is to uninstall it rather than delay the tenant.
• Availability ignores reservations. On hand synced rather than available, so the store promises what is already committed elsewhere.
• Orders duplicate. No idempotency key, so a retry against a throttled endpoint creates a second document, discovered in the warehouse rather than in the log.
• Nobody recorded what the ERP returned. When a price is disputed months later, there is no answer to what Business Central actually said at the time.