BigCommerce with Dynamics NAV or AX, when the ERP already has a successor.

These come one at a time from Microsoft's own lifecycle pages, because the versions differ by months and the summaries floating around the partner ecosystem get them wrong.

• Dynamics NAV 2016: extended support ended 14 April 2026. Behind us.
• Dynamics NAV 2017: extended support ends 11 January 2027. That is the closest live date on this page.
• Dynamics NAV 2018, the final NAV release: extended support ends 11 January 2028.
• Dynamics AX 2012 R3, the final on-premise AX release: extended support ended 10 January 2023.

Two of those deserve to be pulled out.

If you are on NAV 2017, you have months rather than years. Not an emergency, but it is close enough that any integration work planned for this year should be planned with the migration in mind rather than after it.

If you are on AX, you are already unsupported, whichever version you run. AX 2012 R3 was the last release to carry the AX name and it left support in January 2023. The successor, Dynamics 365 Finance and Operations, is the same code line under a different name, and Microsoft does support an upgrade into it from AX 2012 R2 or R3, bringing custom X++ forward through a code upgrade service and your full transactional history through a data upgrade. What you do not have is a supported AX to sit on while you plan that, and worth being straight about it: nothing has stopped working, but nothing is being fixed either.

Check any of it at Microsoft's lifecycle product pages. If a partner quotes you a different date, that is where to settle it.

The instinct when an ERP has an end date is to freeze everything around it until the migration is done. That is usually the expensive choice, because the migration slips and the storefront spends two years not earning what it could.

The storefront and the ERP are separate decisions. What the end date actually changes is one thing: how much of your integration is allowed to know that it is talking to NAV or AX.

Build it so the storefront talks to your own integration layer, and that layer talks to the ERP. When NAV becomes Business Central, or AX becomes Finance and Operations, you rewrite one adapter and run a test suite. Build it the way most of these were built, with ERP field names and document types spread through the storefront code, and the ERP migration drags a full storefront rebuild along behind it.

That is the whole argument, and it makes the project smaller rather than larger, which is worth saying given who is making it.

NAV is the easier of the two to integrate and the easier to migrate afterwards, because Business Central is genuinely the same lineage rather than a different product wearing the family name.

The routes in:

• Page and codeunit web services. The right answer. NAV exposes pages and codeunits as SOAP, and from NAV 2013 onwards it exposes pages and queries as OData. Codeunits are SOAP only on NAV; reaching one over OData is a Business Central capability rather than a NAV one. Publishing a codeunit written for the purpose is far better than exposing a stock page and hoping the shape is stable.
• OData for reads. Straightforward, cacheable, and the closest thing NAV has to a modern surface. Prefer it for catalogue, pricing and availability reads.
• Direct SQL reads. Workable, and the usual caution applies: NAV's table structure is not a public contract and it moves between versions.
• Direct SQL writes. No. NAV's business logic lives in code, not in the database, so writing around it produces records that post incorrectly or not at all.

Why the migration is kinder here: Business Central kept the same data model and the same posting logic, and the move is largely C/AL to AL extensions. A NAV integration built against published web services, rather than against table internals, ports to Business Central with the adapter rewritten and the contracts unchanged. That is not true of the AX path.

AX is the harder case, on both sides. The integration surfaces are older, and the destination is further away.

The routes in:

• AIF, the Application Integration Framework. The sanctioned path in AX 2012, with document services and custom services over several transports. Verbose to work with, and it does respect AX's business logic, which matters more than the ergonomics.
• Custom services. Usually the pragmatic choice: write a service that answers the specific question the storefront asks, rather than bending a document service into that shape.
• The .NET Business Connector. Present in a lot of older integrations, deprecated, and not something to build new work on.
• Direct SQL reads. Common, and riskier than in NAV because AX's table layout is genuinely hostile to outsiders, with surrogate keys and per-company data separation that is easy to get subtly wrong.

Why the migration is harder: Microsoft does tool this one, with a code upgrade service that converts existing X++ and a data upgrade that carries full transactional history. It is still an upgrade project rather than a version bump, and Microsoft says as much: the tooling is described as a framework rather than a complete solution, virtual companies and data partitions block the upgrade outright, and AX 2012 RTM is not a supported starting point at all. The data model is substantially reworked and AIF is gone in favour of OData and the Data Management Framework, so the integration surface you built against does not come with you. An AX integration therefore has a shorter useful life than a NAV one, which argues for keeping the ERP-specific part as small and as isolated as you can get away with.

If that sounds like the argument we make about legacy .NET applications generally, it is the same argument. We wrote it up in legacy .NET modernization, and AX shops tend to be carrying several of the other systems described there too.

The same six every B2B storefront asks of its ERP. Writing them in your own vocabulary rather than NAV's or AX's is the concrete form of everything above, and it costs nothing today.

1. Who is this customer. The customer account behind the login, plus ship-to addresses. In AX, also which legal entity, because per-company data separation will bite you otherwise.
2. What do they pay. NAV sales prices and line discounts, or AX trade agreements. More below.
3. What can they have. Availability by location or warehouse, net of reservations, not just quantity on hand.
4. Place the order. Returning the real ERP order 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.

Across the three pages in this set, pricing is what actually decides the cost of the integration, and NAV and AX land in the middle.

NAV uses sales prices and sales line discounts, and they do not key on the same thing. Prices resolve by customer, customer price group, campaign, all customers and date. Line discounts resolve by customer, customer discount group, campaign and date, against either an item or an item discount group. Customer Price Group and Customer Disc. Group are separate fields on the customer card, and treating them as one is the most common NAV pricing misconfiguration we find. Quantity breaks, unit of measure and currency are all in the mix, and NAV takes the lowest price with the highest allowed line discount. That is more than a flat lookup and much less than a full calculation. For a simple setup, synchronising into BigCommerce price lists works. Once campaigns and overlapping discounts are in play, ask NAV.

AX uses trade agreements, the more capable of the two: price, line discount, multiline discount and total discount journals keyed to a customer, a customer price or discount group, or all customers, with date ranges and quantity breaks. The combinations are not interchangeable, and this is where scoping goes wrong. A price has to name a specific item, because a price is an absolute value rather than a rule. Multiline discounts work at group level only. Line and multiline discounts can combine, depending on how the accounts receivable discount parameter is set. Treat AX pricing closer to how we treat SAP: ask the ERP at cart time and cache the answer.

The rule that holds for both, and for GP:

• Catalogue and search can show a cached or indicative price. Nobody is invoiced from a listing page.
• Cart, quote and checkout must be the live ERP number, because that is what gets posted.
• No resolved price means no add-to-cart. Neither NAV nor AX refuses an order when no customer-specific price exists. NAV falls back to the item card unit price and AX to the released product base price, or to zero if one was never set. Those orders post cleanly and surface as a margin problem months later, which is why the storefront should gate it rather than let the ERP guess.

• The integration was built against table internals. Fine until an upgrade, then quietly wrong. It is also the single thing that turns a Business Central or F&O migration from an adapter rewrite into a rebuild.
• The AX company context is implicit. Someone assumed one legal entity, and the second one produces confidently wrong prices and stock.
• 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 creates a second order, discovered in the warehouse rather than in the log.
• Everything runs through one aging middleware job that one person understands, on a schedule nobody has reviewed since it was set up.
• Nobody recorded what the ERP returned. When a price is disputed months later, there is no answer to what NAV or AX actually said at the time.