How to handle ecommerce when you migrate from Dynamics NAV to Business Central

Short answer.

Your research will usually point clearly at Abakion B2B Ecommerce, at Shopify, or at a larger project, and knowing which one you're facing is worth more than another year of postponing the migration.

Migrating from Dynamics NAV to Business Central online moves your data but not your objects. In a NAV solution the web shop integration usually lives inside the ERP as custom fields, codeunits and modified base objects, and Business Central online locks the base application, so all of it has to be rebuilt as extensions.

Two scenarios turn the ecommerce side of your project into configuration rather than a project: move B2C to Shopify and use Microsoft's Shopify Connector, or move B2B inside Business Central with Abakion B2B Ecommerce.

What are the three ways forward?

There are three real options for ecommerce when you migrate from Dynamics NAV to Business Central, and it's worth naming all of them.

1. Keep your storefront and replace the connection. Sensible if the platform is current and has a supported Business Central connector, which the serious ones do. You still pay for a re-integration project, but you don't replatform.
2. Move B2C to Shopify and use Microsoft's Shopify Connector.
3. Move B2B into Business Central with the Abakion B2B Ecommerce app.

The first is a project. The other two are mostly setup.

Why Dynamics NAV companies keep postponing the migration

If you're still on Dynamics NAV, the direction has already been decided for you. NAV 2016 lost extended support in April 2026, NAV 2017 goes in January 2027, and NAV 2018, the final version, ends in January 2028. There's no NAV 2019 coming, so the only open question is when you move and how much you rebuild on the way.

For a lot of companies, the thing that keeps pushing that date out is not the general ledger, because the finance side of a Dynamics NAV migration is well understood by now. It's the web shop.

The worry is usually specific, and it's usually correct. Your online store is wired into Dynamics NAV, in many cases literally inside NAV, and nobody wants to discover on go-live weekend what happens when the objects underneath it are replaced. So the ERP project quietly acquires a second project, a web project, and the web project is the one with the uncertain number attached.

There are two scenarios where that second project turns into configuration instead, one for B2C and one for B2B, and they're worth knowing about before you price the alternative.

One premise first. Everything below assumes Business Central online, because every app on Microsoft Marketplace requires the cloud version, and on-premises is not a realistic destination for a company leaving Dynamics NAV today. So when we write Business Central, we mean the cloud.

What migrates from Dynamics NAV to Business Central, and what doesn't?

Your data migrates. Your objects don't.

Start with the good news, because there's more of it than a Dynamics GP customer gets. Business Central is NAV's direct descendant, so the data model is the same one you've been working in for years. Item numbers are 20 characters in both, so nothing gets renumbered. Locations are still locations, dimensions are still dimensions, variants are still variants. Microsoft's cloud migration tool replicates your data, including posted history, which means the order history behind "my orders" on your website survives the move. Your users will recognise the screens.

That last point is worth isolating, because it's the single biggest difference from a Dynamics GP migration. A NAV company usually keeps its order history, its item numbers, its variants and its item attributes. A GP company usually doesn't.

What doesn't survive is everything a developer wrote. In Business Central online the base application is locked, so every modified object, every custom field and every piece of C/AL that touches your web shop has to be rebuilt as an AL extension.

Which upgrade route do you have?

That depends on your NAV version, and the path has more steps than it used to.

Dynamics NAV cannot be cloud-migrated directly. You upgrade to Business Central on-premises first, then switch to Business Central online. Microsoft's guidance for on-premises versions 14 through 24 is to upgrade to at least version 25 on-premises before migrating online, because version 25 is the stepping-stone release: direct cloud migration and data upgrade from version 14 was removed in version 26.

At the point where you leave C/AL behind, you choose between two shapes. A full migration converts your C/AL customisations to AL extensions. A reimplementation takes master data, balances and a subset of history, and leaves the customisations behind.

Both routes have the same consequence for your web shop.

Where does the web shop integration actually live in a Dynamics NAV solution?

Inside the ERP, not beside it. In a NAV solution the web shop integration is rarely a separate system sitting politely alongside the ERP. It's a set of objects within it.

A few custom fields on the Item table for web description, web category and "show on web". Another on Customer for the login mapping. A codeunit that builds the catalogue export, and a modified Sales Line so web orders post the way the shop expects them to. Possibly a NAS instance running the whole thing overnight, because that's what NAS was for.

That was the right design in Dynamics NAV, where the base application was yours to modify. Business Central online locks the base application, so every one of those objects has to be rebuilt as an extension, and every custom field has to be re-created as a table extension with a new field number and a deliberate decision about whether anything outside the system can still see it.

Finding them all is harder than it sounds, because the Modified flag in NAV can be overwritten, so filtering on modified objects does not reliably give you the full list. An honest inventory of what the shop touches is the first piece of real work in this project, and it's worth doing before anyone quotes you a price.

Which integration methods stop working in Business Central online?

Four of them, on a published schedule.

Direct SQL access against the company database is the first casualty, and there is no equivalent in Business Central online.

NAS, the NAV Application Server, is gone. Background processing belongs to the job queue now.

Basic authentication for web services was deprecated for Business Central online in 2022, so anything still using a web service access key needs OAuth2.

SOAP endpoints on Microsoft pages are being removed. Since version 26 it has not been possible to publish a Microsoft UI page as a SOAP web service unless the corresponding feature key is turned off in Feature Management, and Microsoft has stated that support for publishing Microsoft UI pages as SOAP web services is removed in Business Central 2026 release wave 2, version 29.0. Microsoft has signalled that publishing Microsoft UI pages as OData endpoints follows, in the 2027 release wave 1. The replacement in both cases is API pages, which are purpose-built for integration rather than being a user interface borrowed for the job.

SOAP has been in the platform since NAV 2009, so there's a good chance your web shop connection was designed around it. If it was, the deadline is closer than your migration date.

What happened to the sales price tables?

They were replaced, and then removed. This one breaks integrations silently rather than loudly.

The old sales price and sales line discount tables were unified into price list headers and lines in the new pricing experience, and in version 26 the old tables went from obsolete to removed. Any code that reads table 7002 is reading a table that no longer exists.

If your web shop calculates prices by reading NAV's price tables directly, and many of them do because it was faster than calling into the pricing codeunit, that logic has to be rewritten against price lists. That's not a translation exercise, because the new model handles customer groups, campaigns, currencies and date ranges differently from the tables it replaced.

The same quiet-removal pattern applies elsewhere. Product groups were replaced by item categories and item attributes back in NAV 2017, so if you're coming from NAV 2013 or 2015 and your shop's navigation is built on product group codes, the categorisation has to be rebuilt before the catalogue can be exported at all.

What changes about owning an integration long term?

It stops being a one-off and becomes a standing commitment. This is easy to miss when you're focused on the migration itself.

A Dynamics NAV integration could sit untouched for eight years, because nothing underneath it moved unless you moved it. A Business Central integration meets a new major version twice a year, and service protection limits apply to how hard it can call the system, so the nightly full-catalogue export that used to be a SQL query now has to be designed around throughput quotas.

None of that is unreasonable, but it does mean somebody owns regression testing of the shop integration from now on, permanently. Which is a strong argument for owning as little integration as you can get away with.

And if your shop runs on an ISV connector built for Dynamics NAV, ask early whether the Business Central version is the same product or a new one, because in several cases it's a different platform generation with its own licence and its own implementation project.

When does the Microsoft Shopify Connector fit?

The Shopify Connector fits Dynamics NAV companies whose ecommerce revenue is mostly B2C with a straightforward catalogue.

The Shopify Connector is built by Microsoft and preinstalled in new Business Central online environments, so there's no middleware to licence, no server to patch and nobody in the middle. Synchronisation runs on the job queue inside Business Central.

It covers more than people expect. Items sync both ways, including variants, images, barcodes, vendor item numbers, tags and metafields, and you can export item attributes, extended texts and translations. Inventory syncs across the locations you choose. Customers and companies sync both ways with mapping on email, phone or registration number. Orders come in from the online store, from Shopify POS and from Shopify B2B, along with shipping costs, gift cards, refunds, cancellations and payout information from Shopify Payments. Posted invoices go back so buyers can find them in their own account.

What that means coming from Dynamics NAV:

Catalogue data. The data side of that list is the part to notice. Item attributes, extended texts, variants and translations are already in your system, because NAV has had them for years, so you're not starting the catalogue from nothing the way a company on an older ERP would be.

Architecture. You lose a moving part rather than gaining one. The old pattern was Dynamics NAV, custom objects, connector, storefront. The new pattern is Business Central and Shopify, with Microsoft responsible for the connection and both ends on their own release cadence.

Pricing. Shopify holds the storefront price, and Business Central exports it based on customer price groups and discounts once you're on price lists. For consumer selling, that's usually a simplification you should welcome, because the complexity in a NAV price setup is almost always there for trade accounts rather than consumers.

Inventory and orders. Availability comes from Business Central's own calculation, order to cash stays in Business Central, and fulfilment goes back to Shopify. For companies selling into the US, Shopify calculates sales tax at checkout and you keep an engine such as Avalara behind Business Central for posting and filing.

Limits. Be clear-eyed about them. Microsoft deliberately keeps the extension points few so the connector can follow Shopify's release pace without breaking things. It's one shop per configuration, so selling into Amazon or another marketplace needs something else. Shopify's B2B features, improved as they are with catalogues through Markets and volume pricing, still strain under complex contract pricing. And you have to stay current on Business Central versions, because the connector follows the platform.

When does Abakion B2B Ecommerce fit?

Abakion B2B Ecommerce fits Dynamics NAV companies whose ecommerce revenue is mostly B2B, where prices, agreements and assortments are already maintained per customer in the ERP.

B2B is a different problem, because your customers aren't browsing. They're doing a job on their own terms, with their own prices and agreements, and the number on the screen has to match the number on the order confirmation.

That's exactly what breaks in the traditional model, where prices, assortments, stock and terms are copied out of the ERP and kept in sync, so every agreement is maintained twice and every mismatch becomes a phone call to your sales office.

Abakion B2B Ecommerce removes the copying. The app is installed in Business Central, the site is hosted on Azure, and the storefront reads live data from Business Central. There's no synchronisation job, no staging database and no integration for you to own, which also means there's nothing to regression test twice a year.

What that means coming from Dynamics NAV:

You've already done the work. Ten years of price lists, customer discount groups, blanket agreements, currencies, units of measure and availability setup are the thing the shop displays. A customer signs in and sees their items, their prices and their terms.

Availability and delivery dates come from Business Central's own calculation, so the promise on the website is the promise the ERP would make. Order history and reorder come from their actual posted documents. For US sales tax, the app supports Avalara.

Product content is the one place to invest, and it's the same investment either way. Web texts, images and enriched attributes need to live in Business Central rather than in the old storefront, which is what the accompanying Master Data Information app handles, along with variant matrices for size and colour ranges.

Commercial shape. It's shaped like an app rather than a project, with a fixed-price initial setup and then a subscription tiered by number of active customers and items in the shop. That's a shorter budget conversation than a replatform, and a much shorter one than rebuilding a bespoke integration against a moving API.

In what order should you sequence the two projects?

Move the ERP first, then move the storefront once, onto the model you're actually going to keep.

The most expensive mistake available to you right now is spending 2026 fixing your Dynamics NAV integration. The SOAP and OData deadlines are real, so there's genuine pressure to modernise the connection. But if Business Central is on your roadmap anyway, every hour spent making the old integration survive another year is an hour you write off, and you end up with two web projects in two years instead of one. Keep any change to the current setup thin and disposable.

If you're taking the reimplementation route, decide what happens to the custom fields your shop depends on before the reimplementation, not after. That decision is cheap in a workshop and expensive in a test cycle.

When is neither Shopify nor Abakion B2B Ecommerce enough?

Both of these paths trade flexibility for speed, and that trade doesn't suit everyone. Neither option fits if you:

• sell configurable products
• run punchout or EDI into your customers' procurement systems
• sell across several marketplaces
• operate a subscription model
• run a design-led consumer brand where the storefront is the marketing

In those cases you need a large ecommerce platform and a customized project.

The point isn't that nobody needs an ecommerce project. It's that plenty of Dynamics NAV companies assume they do, and then spend three more years on an ERP with a published end date because of an assumption nobody actually tested.

Where to start

Five questions will tell you which path you're on:

1. Which Dynamics NAV version are you on, and which upgrade route does that give you?
2. How does the shop talk to NAV today: direct SQL, NAS, SOAP, OData, or an ISV connector?
3. Which custom fields on Item, Customer and Sales Header does the shop depend on?
4. Does the shop read the old sales price tables, or does it call into pricing?
5. Is your ecommerce revenue mostly B2C, mostly B2B, or genuinely both?

The answers usually point clearly at Abakion B2B Ecommerce, at Shopify, or at a larger project, and knowing which one you're facing is worth more than another year of postponing the decision.

Frequently asked questions

Both apps are on Microsoft Marketplace

• Shopify Connector, published by Microsoft
• Abakion B2B Ecommerce
• Abakion B2B Ecommerce product page

Sources

• Migrate on-premises data to Business Central online, Microsoft Learn
• Deprecated features in the platform, Microsoft Learn
• SOAP web services in Business Central, Microsoft Learn
• Deprecated features in the base app, Microsoft Learn
• Shopify Connector overview, Microsoft Learn
• Shopify Connector FAQ, Microsoft Learn