Moving ecommerce: Dynamics AX to Business Central

Short answer.

The answers usually point clearly at Abakion B2B Ecommerce, at Shopify, or at a larger rebuild, and knowing which one you're facing is worth more than another year on an ERP that stopped getting security updates in 2022.

Migrating from Dynamics AX to Business Central rebuilds your web shop connection rather than moving it. There is no Microsoft migration tool between the two systems, and none of the technologies an AX storefront depends on, AIF, the .NET Business Connector, direct SQL or the AX Retail channel database, has a counterpart in Business Central online, where the only supported way to read data is the API.

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

What are the three options, and how do they compare?

There are three real options for ecommerce when you migrate from Dynamics AX to Business Central, and the first one is the one most companies assume is the only one.

Keep your storefront and rebuild the connection. Sensible if the platform is genuinely good and recently built. You still own the integration, the mapping and the regression testing, for as long as you keep it.
Move B2C to Shopify and use Microsoft's Shopify Connector.
Move B2B into Business Central with the Abakion B2B Ecommerce app.

The first is a project you keep owning. The other two are mostly setup.

	Existing storefront, new API integration	Shopify with Microsoft's Shopify Connector	Abakion B2B Ecommerce
Product	Your current platform plus custom middleware	Shopify plus Shopify Connector for Business Central	Abakion B2B Ecommerce, plus Master Data Information
Who it's for	B2B or B2C with unusual requirements	Business to consumer, and simpler B2B	Business to business
Architecture	Storefront and Business Central synchronised through your integration	Connector inside Business Central online, sync on the job queue	App in Business Central, site on Azure, live reads
Data copy	Yes, in your integration and its mappings	Yes, Shopify holds its own catalogue	No, the storefront reads Business Central directly
Pricing source	Whatever you build	Business Central prices synchronised to Shopify	Business Central, live, including customer agreements
Availability	Whatever you build	Inventory synchronised per selected location	Business Central availability calculation
Product content	Wherever it lives today	Shopify, fed from Business Central items and attributes	Master Data Information in Business Central
Twice-yearly regression testing	Yours	Microsoft's	None to do
Commercial shape	Project plus ongoing development budget	Business Central licence plus Shopify subscription	Fixed-price project, then tiered subscription
Best fit	You have requirements neither of the other two covers, and you accept owning an integration for as long as you run the shop	You sell to consumers, or to businesses with straightforward pricing, and you want the integration to be Microsoft's problem	You sell to businesses on customer-specific prices and agreements, and you want no integration at all

Why is this urgent for Dynamics AX customers in 2026?

Dynamics AX has been out of support for years. Mainstream support for Dynamics AX 2009 SP1, Dynamics AX 2012 and Dynamics AX 2012 R2 ended on 9 October 2018, and the extended period that followed, where the only thing you got was security hotfixes, ended on 12 April 2022. Dynamics AX 2012 R3 ran a little longer, with mainstream support ending on 12 October 2021 and extended support on 10 January 2023. So if you're running any version of Dynamics AX today, you're running a system that hasn't had a regulatory update in years and hasn't had a security fix since early 2023.

Most companies in that position have known for a while, and many of them have already worked out what the replacement looks like. Some are going to Dynamics 365 Finance and Operations, which is the route Microsoft documents. Others are going to Business Central, because the company that bought Dynamics AX in 2012 isn't the company that exists now. Maybe a division was sold off. Maybe the group standardised somewhere else and one entity is left over. Maybe Dynamics AX was over-specified from the start and nobody wants to pay for that scale twice.

And in a lot of those companies, the thing holding the decision up isn't the ledger. It's the web shop.

That fear is reasonable, because a Dynamics AX web shop is usually wired into the ERP at a depth that no accounting comparison captures. But it's worth being precise about what the actual problem is, because the answer changes depending on which problem you have.

Your chart of accounts can be rebuilt from a trial balance. Your SKUs can't.

One premise before we go further. Business Central here means Business Central online. Microsoft's own documentation states that you can't install Marketplace apps on-premises, including in Docker-based deployments, and that includes Microsoft's own Shopify Connector. So every option in this article assumes the cloud, and we won't cover the on-premises scenario at all.

Is there a migration tool from Dynamics AX to Business Central?

No. The Business Central cloud migration tool supports Business Central on-premises, Dynamics NAV, Dynamics GP 2015 and later versions, Dynamics SL 2015 and later versions, and a generic option for any other SQL source using custom migrations. Dynamics AX is not on that list.

It isn't a gap that's about to be filled either, because Microsoft's own migration guidance routes Dynamics AX 2009 and Dynamics AX 2012 customers to the Dynamics 365 Finance and Operations apps instead, with AX 2012 and R2 upgrading to AX 2012 R3 first. Microsoft published migration guidance for legacy customers in July 2026 and it covers Dynamics NAV, Dynamics GP and Dynamics SL. Dynamics AX isn't mentioned.

Start with the honest good news, though. Nothing in your finance function is unusual. Chart of accounts, customers, vendors, items, open receivables and payables, open orders: all of that is ordinary migration work with a known shape, and a competent partner has done it many times.

The exception is everything the web shop touches. Because every Dynamics AX to Business Central project is a bespoke data migration, nothing about your web shop comes along for free. There's no wizard that reads your Dynamics AX product master, and no snapshot that carries your posted invoice history into extension tables the way the Dynamics GP migration does. Whatever the storefront depends on either gets rebuilt deliberately or it stops working on go-live day.

Does AIF work with Business Central?

No. AIF, the .NET Business Connector, direct SQL against the Dynamics AX company database and the AX Retail channel database all stop working when you move to Business Central online, and none of them has a replacement of the same shape.

Before you can price the work, you need to know what your storefront is actually talking to, and in a Dynamics AX estate it's usually one of four things.

AIF and document services. If your storefront posts orders through the Application Integration Framework, it's probably calling `SalesSalesOrderService`, reading customers through `CustCustomerService`, items through `InventItemService` and availability through the read-only `InventInventoryOnHandService`. Enhanced integration ports gave you HTTP, NetTCP, MSMQ and file system adapters, and plenty of shops used more than one.

The .NET Business Connector. Running under a proxy account with the `SysBusinessConnectorRole`, executing X++ against the AOS. That was always the fast way to get at logic AIF didn't expose, and it's still in production in a lot of places.

Direct SQL against the Dynamics AX company database. Usually for the read side, because it was the only way to get an answer quickly enough for a category page.

The AX Retail Commerce stack. A channel database, Commerce Data Exchange pushing data out on Distribution Scheduler jobs, the Commerce Runtime, and in Dynamics AX 2012 R3 a Retail Server exposing OData. If your online store is the SharePoint one Microsoft shipped with Dynamics AX 2012 R2 and R3, you also have an identity provider database holding your customers' web credentials and a claims provider database mapping each web login to a Dynamics AX customer account.

The reason none of it survives is architectural rather than a matter of effort. For Business Central online, in Microsoft's words, the only supported option for reading data is using APIs. There's no database to point at, no application server to call into, and no X++ to execute. The integration isn't ported, it's rewritten.

What changes about owning an integration long term?

It stops being a one-off and becomes a standing commitment, on a platform that moves on its own schedule.

A Dynamics AX integration could sit untouched for a decade, because AIF, the Business Connector and the channel database don't change unless you change them. A Business Central integration meets a new major version twice a year, and it gets rewritten against a moving set of protocols on top of that. SOAP was replaced by OData V4, and exposing Microsoft's own UI pages as SOAP endpoints is removed in 2026 release wave 2, version 29.0. API v1.0 was made obsolete in 2024 release wave 1 and removed in 2026 release wave 1, version 28.0. Web service access keys and basic authentication stopped working for Business Central online on 1 October 2022.

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

Do item numbers and product variants change when I move from Dynamics AX to Business Central?

Yes, and product variants are the single most disruptive field-level change in the whole migration.

In Dynamics AX, the thing you sell is a global product, released into a legal entity where it picks up an item number, addressed by that item number plus up to three product dimensions: configuration, colour and size. Microsoft's guidance for that product family says the product number should be 20 characters or fewer, ideally fewer than ten.

In Business Central, an item has a `No.` field of `Code[20]`, and Item Variant has a single flat `Code` of `Code[10]`. There's no dimension model underneath it and no variant matrix, so you create `RED` and `S` and `M` individually.

So a Dynamics AX product with colour, size and configuration has to be flattened into one ten-character code. `BLACK-XXL-CONFIG2` doesn't fit. Every variant your storefront knows about has to be re-minted, and everything keyed on it moves with it: product URLs, cart lines, wishlists, historical order lines, the SKU column in your Google Shopping feed, and the barcode mapping in your warehouse app.

There's a second, quieter one. Business Central's `Code` data type converts to uppercase and strips leading and trailing spaces. If any of your Dynamics AX item numbers or customer accounts contain lower-case letters, they change identity on arrival, and a URL slug built from a mixed-case item number is a broken link.

In Dynamics AX, an item number is an internal key. On your web shop it's a public URL.

How do Dynamics AX trade agreements map to Business Central pricing?

They don't map one to one, and multiline discount has no Business Central equivalent at all. If there's one section to read twice, it's this one.

Dynamics AX prices through trade agreements, entered on journals and posted, where each line carries an item relation, an account relation, currency, unit, quantity break and validity dates. On top of that, AX Retail adds price groups, which is the mechanism that let you hang a different price on the same product for a specific channel, catalogue, affiliation or loyalty programme. Then price adjustments, with simple, quantity, threshold and mix-and-match discounts, and an engine that picks the combination giving the customer the best price.

Business Central has price lists, assigned to a customer, a customer price group, a campaign or all customers, with minimum quantity, unit of measure, currency and dates on the line. It picks the lowest unit price and the highest allowed line discount that match. Invoice discount is a single document-level percentage per customer above a threshold.

Read those two paragraphs next to each other and you can see the shape of the problem.

Multiline discount, where Dynamics AX accumulates quantity across several lines of the same group and then discounts them, has no equivalent, because a Business Central line discount is per line and an invoice discount is flat across the document.
There's no channel concept in Business Central, so a web-shop-only price that used to be a channel price becomes a customer price group that every web customer has to be assigned to.
Mix-and-match and threshold discounts aren't there, and neither is a best-price-combination engine.
Dynamics AX could price on colour or size, where Business Central price list lines key on item, variant and unit of measure and nothing below that.
Dynamics AX prices arrived through posted journals with an audit trail, so anything reading trade agreement journals has nothing to read.

Which means one of two things is true about your storefront today, and you should find out which before you plan anything. Either it asks Dynamics AX for a price on every line, in which case the rules have to be redesigned to match what Business Central can actually calculate. Or it holds its own copy of the pricing logic, which is worse. If your web shop calculates its own prices today, you don't have one pricing engine. You have two, and they disagree at the worst possible moment, which is the moment a customer compares the basket to the invoice.

Why does inventory availability behave differently in Business Central?

Because Dynamics AX answers an availability question across inventory dimensions and can return a promise date, while Business Central returns a quantity per item, location and variant.

The Dynamics AX on-hand list distinguishes physical inventory, physical reserved, available physical, ordered in total and total available, and the dimensions you ask for change how those numbers aggregate. On top of that, delivery date control could run ATP or CTP and give the storefront a promise date.

Business Central gives you quantity on hand per item, location and variant, plus availability views by event, by period, by location and by variant. Its order promising exists, with ATP and CTP, but it's an action a user runs on selected sales lines rather than an endpoint an integration calls. If your product page says "available at your site by Thursday", it's reading something Business Central doesn't expose.

Where does product content live after the move?

Not in Business Central, in most cases, because Business Central's item card is a much thinner content surface than a Dynamics AX Retail product record.

If you ran AX Retail, you didn't just have an item master, you had a product information layer inside the ERP: attribute types and attribute groups carrying rich text and images, attributes declared at category level and inherited by every product in the category, per-channel flags for whether an attribute was required, searchable, filterable or visible, several category hierarchies at once, and assortments deciding which products a channel could even see.

Business Central has item categories in one hierarchy, and item attributes that Microsoft's own documentation describes as search words in integrated web shops. Item description is `Text[100]` with a second description field of `Text[50]`. So everything your storefront was reading from assortments and category-scoped attributes has to live somewhere else now, either in the storefront or in a product information tool.

What happens to order history and customer logins on go-live day?

Posted Dynamics AX invoices don't become posted Business Central invoices unless someone builds that, and web logins survive only if the storefront survives, because the customer-number mapping breaks when item and customer numbers are re-minted.

History is the easier one to be honest about. Most projects load open balances and keep the old Dynamics AX data as an archive or a reporting copy, because there's no tooling to do otherwise. Even for Dynamics GP, the one legacy line Microsoft does tool, detailed history lands in separate extension tables rather than as native posted documents.

Logins are more interesting, because in the AX Retail online store the credentials were never in Dynamics AX at all. They sat in an identity provider database for forms-based authentication, with a separate claims provider database mapping each login to a Dynamics AX customer account. So the logins survive if the storefront survives, but the mapping breaks the moment customer numbers are re-minted or uppercased, and a customer whose login resolves to nothing gets an empty account page. Business Central cloud migration doesn't carry users and permissions in any case, even for the sources it supports.

When does the Microsoft Shopify Connector fit?

The Shopify Connector fits Dynamics AX companies whose ecommerce revenue is mostly B2C with a straightforward catalogue, or B2B with pricing simple enough for Shopify's catalogues.

Architecture. The Shopify Connector is built by Microsoft, ships preinstalled with Business Central online, and runs on the job queue. There's no middleware to licence, no server, and nobody in the middle. It isn't available for on-premises deployments.

Data flow. Item sync is bidirectional and covers variants, images, barcodes, vendor item numbers, tags and metafields, and it exports item attributes, extended and marketing texts and translations. Inventory syncs across the locations you select. Customers and companies sync both ways, with mapping on email, phone or registration number.

Orders. Order import covers the Shopify online store, Shopify POS and Shopify B2B, and brings shipping costs, gift cards, tips, refunds, cancellations and payouts from Shopify Payments. Fulfilment tracking goes back to Shopify, and posted sales invoices are exported.

Tax. If you sell into the US, Shopify calculates sales tax at checkout and an engine such as Avalara sits behind Business Central for posting and filing.

Limits. Extension points are deliberately few, because that's how Microsoft keeps pace with Shopify's release cycle without breaking changes. It's one shop per configuration, so other marketplaces need something else. B2B works through Shopify companies and catalogues, and B2B company sync was extended to more Shopify plans in 2026 release wave 1 with catalogue assignment through B2B Markets, but direct company catalogues and volume pricing require the higher Shopify plans, and complex contract pricing still strains it. And you have to stay current on Business Central versions.

When does Abakion B2B Ecommerce fit?

Abakion B2B Ecommerce fits Dynamics AX companies whose prices are customer-specific and whose customers reorder, which describes most Dynamics AX B2B estates.

Architecture. Abakion B2B Ecommerce installs as an app in Business Central, the site runs on Azure, and the storefront reads live data from Business Central. There's no synchronisation job, no staging database, no integration to own, and nothing to regression test twice a year.

Data flow. Customer-specific catalogues, prices, agreements and currencies come straight from the ERP, and delivery dates come from Business Central's own availability calculation. Order history and reorder work from actual posted documents.

Product content. The accompanying Master Data Information app handles product content and variant matrices, and this is the one place you have to invest, because your web texts and images almost certainly live in the old storefront rather than in Dynamics AX.

Tax. Avalara is supported for US sales tax.

Commercial shape. Fixed price on the initial project, then a subscription tiered by the number of active customers and the number of items in the shop.

The argument that lands hardest for a Dynamics AX customer. You're going to rebuild your pricing model in Business Central anyway, because trade agreements, price groups and multiline discounts don't survive the move. That rebuilt pricing model is the web shop's pricing. There's nothing to push out to the shop, because there's no out.

In what order should you sequence the two projects?

The ERP first, and the storefront once, afterwards, on the model you intend to keep.

The most expensive mistake available to you is investing in the Dynamics AX integration in the year before you replace Dynamics AX. Every hour spent hardening AIF ports or extending the channel database is an hour written off on go-live day. Design any change to the current setup as thin and disposable. Two web projects in two years is the outcome nobody plans for and plenty of companies get.

There's a real complication for Dynamics AX customers, and it deserves naming rather than waving away. You're not choosing the timing freely, because the system has been out of support since 2022 or 2023, and if the storefront platform is the SharePoint-based AX Retail online store or a Sana Commerce version the vendor has declared end of life, you may have two clocks running at once. If both are urgent, the ERP goes first and the storefront gets a minimum intervention to stay upright, because doing it the other way round means building a connection to a system you're about to switch off.

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 AX 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:

Does your storefront calculate prices itself, or does it ask Dynamics AX for every line? The answer decides how big this is.
How many of your products have more than one product dimension in use, and what would their variant codes look like in ten characters?
Which of your item numbers and customer accounts contain lower-case letters?
What is your storefront actually connected to today: AIF, the .NET Business Connector, direct SQL, or the AX Retail channel database?
Where do your web texts and product images live, and who owns them?

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

Frequently asked questions

Can I migrate from Dynamics AX to Business Central with Microsoft's cloud migration tool?

No. The Business Central cloud migration tool supports Business Central on-premises, Dynamics NAV, Dynamics GP 2015 and later, Dynamics SL 2015 and later, and custom migrations from other SQL sources. Dynamics AX isn't supported, and Microsoft's migration guidance points Dynamics AX customers to the Dynamics 365 Finance and Operations apps instead. A Dynamics AX to Business Central move is a bespoke data migration project.

Is Dynamics AX still supported?

No. Mainstream support for Dynamics AX 2009 SP1, Dynamics AX 2012 and Dynamics AX 2012 R2 ended on 9 October 2018 and extended support ended on 12 April 2022. For Dynamics AX 2012 R3, mainstream support ended on 12 October 2021 and extended support ended on 10 January 2023. There are no security updates and no regulatory updates after those dates.

Do item numbers change when I move from Dynamics AX to Business Central?

Usually yes, and variant codes almost always do. Business Central's item `No.` is 20 characters and Item Variant `Code` is 10 characters, and both are the `Code` data type, which converts to uppercase. A Dynamics AX product addressed by item number plus configuration, colour and size has to be flattened into one ten-character variant code. Dynamics NAV customers don't face this problem, because item numbers are 20 characters in both systems.

Can I keep my existing web shop when I move to Business Central?

Yes, but the connection is rebuilt from scratch as an API integration against Business Central online, because AIF, the .NET Business Connector, direct SQL and the AX Retail channel database don't exist there. You then own that integration and regression test it against a new Business Central major version twice a year.

Does Business Central have product variants like Dynamics AX?

No. Dynamics AX supports up to three product dimensions, configuration, colour and size, and identifies a variant as item number plus those dimensions. Business Central has a single flat variant code of ten characters on Item Variant, with no dimension model and no variant matrix.

Can I run the Shopify Connector on Business Central on-premises?

No. Microsoft's documentation states that the Shopify Connector isn't available for on-premises deployments, and that Marketplace apps can't be installed on Business Central on-premises at all, including Docker-based deployments. Business Central online is the only realistic destination if you need connector apps.

Will my customers' web shop logins still work after the migration?

They work if the storefront stays, but the account behind them may not resolve. In the AX Retail online store the credentials lived in a separate identity provider database, with a claims provider database mapping each login to a Dynamics AX customer account. If customer numbers change or get uppercased in Business Central, that mapping has to be rebuilt or the customer sees an empty account page.

What happens to order history in the web shop?

Posted Dynamics AX sales invoices don't arrive in Business Central as posted sales invoices unless the project builds that explicitly. Most Dynamics AX to Business Central projects load open balances and keep historical documents in an archive or reporting copy, so reorder-from-history in the web shop has to be based on Business Central documents created after go-live, unless history is loaded deliberately.

Should I fix the Dynamics AX web shop integration now or wait for Business Central?

Wait, unless something is actually broken. Money spent hardening AIF ports, the Business Connector or the channel database in the year before the ERP move is written off on go-live day. Keep any change thin and disposable, and let the storefront land once, after the ERP move.

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