Moving ecommerce: Sage 200 to Business Central

Short answer.

The answers usually point clearly at Abakion B2B Ecommerce, at Shopify, or at a rebuilt API integration, and knowing which one you're facing is worth more than assuming the current connection carries across.

Sage 200 is not on Microsoft's list of supported cloud migration sources, so a move to Business Central is a bespoke data migration and the web shop integration is rebuilt rather than ported. That rebuild is unavoidable because the three ways a Sage 200 web shop connects today, direct SQL against the Sage 200 database, the Sage 200 .NET SDK, and the Sage 200 REST API, are each either outside Sage's licence agreement, licence-gated to Sage 200 Professional, or explicitly unsupported for custom integration work.

Two routes stop this becoming a second project: move B2C to Shopify with Microsoft's Shopify Connector, or move B2B into Business Central with Abakion B2B Ecommerce. Keeping the existing storefront and rebuilding the connection as an API integration is the third route, and it's the one where you keep owning the integration and regression testing it twice a year.

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

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

Keep the storefront and rebuild the connection as an API integration. Sometimes that's right, particularly if the storefront is good and recent. But be clear about what you're buying, because you own the integration, you own the mapping, and you regression test it against a new Business Central major version twice a year for as long as you keep it. That's a real change from Sage 200, where a version could sit still for three years.
Move B2C to Shopify and use Microsoft's Shopify Connector.
Move B2B into Business Central with the Abakion B2B Ecommerce app.

The other two remove that ownership, and they split by who you sell to.

	Existing storefront, new API integration	Shopify with Microsoft's Shopify Connector	Abakion B2B Ecommerce
Product	Your current platform plus middleware or custom code	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
Who supports the connection	You and your partner	Microsoft	Abakion
Twice-yearly regression testing	Yours	Microsoft's	None to do
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

Does Sage 200 have an end of life date?

No. Sage publishes end of support dates for individual Sage 200 versions, not for the product, and those version dates roll forward with every release.

Nobody has sent you a letter with a date on it, and that's the first thing worth saying out loud.

Sage supports the latest major release minus two major versions, and the dates live in a downloadable lifecycle PDF rather than on a lifecycle page. At the time of writing, Sage 200 2023 R1 and R2 are in extended support until October 2026, 2024 R1 and R2 until October 2027, and 2025 R1 and R2 until June 2028. Sage says plainly that a version's end of support date can be changed at any time. Sage 200 Standard sits outside the policy entirely, because it's always auto-updated to the latest version.

What actually happens when your version goes out of support is more of a squeeze than a switch-off. Sage's own wording is that once a version has been in end of support status for 24 months, the ability to buy users is also removed. The software keeps running.

Sage 200 doesn't have an end of life date. It has an end of buying users date.

So if you're reading this, something else set your timetable. Usually it's one of three things: your Sage 200 Professional install needs SQL Server 2019 or 2022 and Windows Server 2019 or 2022 and the infrastructure refresh has arrived, or your storefront has a deadline of its own, or the one person who understood the integration has left. Adobe Commerce 2.4.4 lost extended support in April 2026 and 2.4.5 loses it in August 2026, so plenty of Sage 200 companies have an Adobe deadline and no Sage deadline.

And that's the moment the web shop stops being a footnote in the ERP decision and becomes the decision.

One premise before we go further. Business Central here means Business Central online. Microsoft states that you can't install Marketplace apps on-premises, including in Docker-based deployments, so on-premises isn't a realistic destination for anyone who needs connector apps, and we won't cover it.

Is there a migration tool from Sage 200 to Business Central?

No. Microsoft's cloud migration tool supports Business Central on-premises, Dynamics NAV, Dynamics GP 2015 and later, Dynamics SL 2015 and later, and a generic option for any other SQL source using custom migrations. Sage 200 is not on that list, and there is no Sage data migration extension the way there is for QuickBooks Desktop and QuickBooks Online.

The finance side is still ordinary work. Chart of accounts, customers, suppliers, stock items, prices, locations, open balances and current transactions all move through Business Central's configuration packages, which cover 27 tables and are the documented route for source systems without a dedicated wizard.

There's a change coming that's worth knowing about. In 2026 release wave 1, Microsoft added a generic custom migration type to the cloud migration wizard, with an AL interface so partners can build reusable migration engines for any SQL source, including non-Dynamics legacy systems, and ship them on Microsoft Marketplace. It went GA on 1 April 2026. But it needs SQL access to the source database, which a Sage 200 Professional customer running on-premises has and a Sage 200 Standard customer does not, because the Sage 200 Standard database is Sage-hosted with no customer SQL access.

What doesn't migrate, by any route, is posted sales history. Posted invoices, credit notes and despatch history aren't in the configuration packages, and blob fields can't be imported through Excel at all, so item images don't come that way either. If your web shop shows customers their invoice history by reading it live from Sage 200, that's a bespoke data project with its own budget rather than a line item in the ERP migration.

Can I connect my web shop to Business Central the same way it connects to Sage 200?

No. Direct SQL, the Sage 200 .NET SDK and the Sage 200 REST API all stop at the Sage boundary, and Business Central online exposes no database and no equivalent SDK, so the integration is rewritten against the Business Central API.

Your web shop is attached to Sage 200 in one of three ways today, and none of them is a portable asset.

Direct SQL against the Sage 200 database. It usually is this, for reading, because that's how you get a category page to load. Sage publishes an index of useful SQL scripts for Sage 200, prefaced with the note that it's a goodwill gesture and that Sage accepts no liability for its use. On Sage 200 Professional sites deployed through the Sage Provisioning Portal, Sage's own knowledge base says that as per the end user licence agreement, direct changes to the database are not supported, and that only partner logins have the database credentials. On Provisioning Portal Azure SQL, the connection string Sage hands out is read-only and expires after a day.

The Sage 200 .NET SDK. The `Sage.Accounting` assemblies, running under Windows authentication. That's Sage 200 Professional only, it requires an ISV or developer programme subscription, and since 2023 R2 the subscription has to be activated or the developer tools don't work.

The Sage 200 REST API. It has existed since 2018 and is enabled by default on Sage 200 Standard. Read Sage's own constraints before you plan anything around it. Initial authentication requires a human via Sage ID, because background services can't perform initial authentication. Access tokens expire after 480 minutes and refresh tokens last 90 days at most, after which a user has to re-authenticate interactively. Queries return at most 5,000 records, `$skip` requires `$orderby`, and the OData `in` filter isn't supported. Only transactional sales invoices come through `sales_invoices`, not invoices raised in the Invoicing module. And Sage Technical Support activates the API and fixes setup, but states that it won't advise on how to use the API, how to call specific endpoints, or resolve errors related to custom integrations once the API is enabled.

That API has also moved once already underneath its users. The original approach for Sage 200 Professional, an externally facing web server with its own certificate, stopped being supported on 19 February 2021 and was replaced by a native API tunnel using Microsoft Entra ID, which needs a supported Microsoft 365 licence, Global Administrator rights and a unique Microsoft 365 tenant per server.

You can't port an integration Sage never agreed you had.

Between the storefront and Sage 200 there's usually middleware too: Codeless Platforms BPA Platform for Magento, Magento 2, Shopware, SHOPLINE and BigCommerce, or Zynk, or Eureka Solutions, or a partner-built API layer. Or the storefront itself is Sage-aware, which in the UK usually means GOb2b, now part of ClearCourse, or Experlogix Digital Commerce, formerly Aphix, or Draycir's Spindle Self Serve for customer self-service ordering.

There's one genuinely good piece of news buried in that list. Two of the largest Dynamics-native B2B storefront platforms, Sana Commerce and Dynamicweb, have no Sage connector at all. So a Sage 200 customer moving to Business Central gains access to a class of ecommerce product that was never available to them, which is the opposite of how migrations usually feel.

Do stock codes and customer accounts change when I move from Sage 200 to Business Central?

Yes for stock codes, because Sage 200 allows 30 characters and Business Central's item `No.` is 20. Customer accounts are the easy direction, because a Sage 200 customer account reference is only 8 characters and Business Central gives you 20.

On a web shop those stock codes are usually the SKU the customer sees, often the canonical part of the product URL, and always the key the storefront matches on. So a shortening exercise in the ERP is a redirect exercise on the website.

Casing catches people out separately. A Sage 200 customer account reference is case-insensitive, so `abc` and `ABC` are the same account. Business Central's `Code` data type converts to uppercase and strips leading and trailing spaces automatically, so a stock code stored as `abc-100 ` arrives as `ABC-100`. Any shop-side lookup that's case-sensitive, and any external reference stored elsewhere, stops matching.

Does Sage 200 have product variants, and what happens to them in Business Central?

No, Sage 200 has no native product variants, and that absence is the most expensive field-level difference in the migration.

There's no variant or matrix concept anywhere on the Sage 200 stock item, which has fifteen tabs and not one of them for the web. Ranges are built as separate stock items, one per combination. If you use Sicon Stock Matrix, you defined a code format from attribute groups and let it generate every combination as its own stock item with its own code, stock and price.

Business Central models the same range as one item with a `No.` of `Code[20]` plus Item Variant records with a `Code` of `Code[10]`.

So this isn't a truncation exercise, it's a shape inversion. In Sage 200, a variant is a different product. In Business Central, it's the same product, so the migration has to decide which was true and then split a string that encoded the whole variant back into a parent and a child that each have to fit a smaller box. `TSHIRT-BLACK-XXL` is one code in Sage 200 and two in Business Central, and `BLACK-XXL` fits in ten characters while `BLACK-XXLONG` doesn't.

And every one of those codes is a live URL on your shop today.

How do Sage 200 price bands map to Business Central price lists?

Most of it maps, but three things don't: multiple simultaneous Limited band membership, quantity break percentages on product groups, and quantity breaks configured as surcharges.

Sage 200 prices through price bands, and each band is essentially a price list. There are three types and the membership rules are what matter. There's one Standard band containing prices for all stock items, linked to all customers by default. A customer can belong to exactly one Universal band, and removing them from it drops them back to Standard. And a customer can belong to many Limited bands at the same time, which is where promotional and special prices live, with active-from and active-to dates. Bands are currency-scoped, and only customers using the same currency can be linked to a band.

On top of that there are six discount mechanisms in Sage 200:

flat rate stock item discounts, as a percentage, an amount or a special price
quantity break discounts, percentage on items or product groups, amount or special price on items only, and configurable as surcharges
product group discounts, percentage only
invoice and order value discounts above a threshold
customer discount groups, where a customer can belong to only one
settlement discounts for early payment

Where a customer qualifies for several prices, the lowest price is used.

Business Central has price lists with an applies-to type and number, so a list can apply to a customer or a customer price group, with currency, unit of measure, minimum quantity and start and end dates on the line. It picks the lowest price with the highest line discount allowed, and falls back to the item card unit price when nothing matches. Invoice discount is a document-level percentage per customer above a minimum, applied only to lines flagged to allow it.

A Universal band becomes a customer price group. A Limited band becomes a price list with dates. Special prices become price list lines, invoice and order value discounts become customer invoice discounts, and settlement discounts become payment terms.

The three that don't map are worth checking against your own setup before you plan anything. A customer belonging to several Limited bands at once has no equivalent membership model in Business Central, so overlapping bands have to be flattened into overlapping price lists and resolved by best-price logic, which is a different rule and will produce different answers in some baskets. A quantity break expressed as a percentage on a product group has no direct construct, because Business Central line discounts key on item or item discount group with minimum quantity on the line. And a quantity break configured as a surcharge has nothing to become at all.

Which means the question to answer first is where your web shop gets its prices. If it calls Sage 200 for a price on every line, the rules have to be redesigned to match what Business Central can calculate. If it holds its own copy of the pricing logic, that's worse, because 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 stock availability behave differently in Business Central?

Because Sage 200 gives an integration one stored number and Business Central gives it a computation.

Free stock in Sage 200 is defined arithmetically as quantity in stock minus quantity allocated, per warehouse location, and the Sage 200 API exposes warehouse holdings, so a shop can poll it and show a green tick.

Business Central has no field called free stock. Availability is a computation across inventory, reservations and outstanding documents, exposed through views by event, by period, by location and by variant. And the date version of the question, when can you actually have it, is answered by order promising, which is an action a user runs on selected sales order lines and accepts rather than an endpoint an integration calls. If your product page promises a date today, that promise has to be rebuilt rather than reconnected.

Where does product content live after moving from Sage 200 to Business Central?

It lives in the storefront today and it has to be moved deliberately, because Sage 200 never held it and Business Central holds more of it than Sage 200 did.

The Sage 200 stock item has an Attachments tab for files and links including images, a Memo tab for additional free text, Analysis codes for classification such as commodity codes and ambient versus cold storage, and Search Categories for finding things faster internally. What it doesn't have is item attributes, marketing descriptions, structured images or any web-specific field. Your web texts and product photography live in Magento or WooCommerce or the B2B platform, because there was never anywhere in Sage 200 to put them.

That means there's nothing to extract from Sage 200, which sounds like good news and isn't quite, because the content is trapped in the platform you're replacing.

Business Central is the richer end of this move. It has item attributes with option and variable types, inherited through item categories, which Microsoft's own documentation describes as search terms for customers in integrated web shops, plus extended text and marketing text on the item, and in 2026 release wave 1 item attributes extend to item variants.

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

Logins survive if the storefront survives, because Sage 200 has no concept of a web user. Order history goes dark on cutover if the storefront was reading it live from Sage 200.

Web shop credentials live in the storefront's own identity store, so they aren't an ERP asset at all and the ERP migration doesn't touch them.

Order history depends on a question you can answer today: does the storefront keep its own copy of orders, or does it read them live from Sage 200? If it reads them live, posted Sage 200 documents have to be deliberately migrated for the account page to keep working, and there's no tool that does that, so it's bespoke work with its own budget.

When does the Microsoft Shopify Connector fit?

When you sell to consumers, or to business customers whose pricing is straightforward enough to express in Shopify 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. In 2026 release wave 1 it also syncs product variant images and can build Shopify product options from item attributes. 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 need 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?

When your prices are customer-specific and your customers reorder, which describes most Sage 200 trade and wholesale businesses.

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 for a Sage 200 customer that's the one place you have to invest, because your web texts and images are in the old storefront and were never in the ERP.

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 Sage 200 customer. Today your shop reaches into Sage 200 through direct SQL the licence agreement doesn't cover, or an SDK that needs a developer subscription, or an API that needs a person to log in every ninety days. With a storefront that reads Business Central directly, 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, unless the storefront has a hard deadline of its own.

There's no Sage 200 end of support date forcing your hand, so the sequencing question is sharper here than for a Dynamics customer with a published end date. The most expensive mistake available to you is spending 2026 rebuilding the Sage 200 integration and 2028 replacing Sage 200. Every hour spent hardening a SQL job or extending an API layer is an hour written off on go-live day, so 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.

The complication is that the deadline you do have usually sits on the storefront. If you're on Adobe Commerce 2.4.5 with extended support ending in August 2026, you can't simply wait for the ERP project. In that case the honest answer is a minimum intervention to keep the storefront upright and supported, explicitly scoped as disposable, with the real decision taken after Business Central is live.

When is neither Shopify nor Abakion B2B Ecommerce enough?

When your storefront has to do something both routes deliberately trade away. 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

Those need a real ecommerce platform and a real project.

But plenty of companies assume they're in that group without testing it, and then spend three more years on an integration nobody supports because of an assumption nobody checked.

Where to start

Five questions, and the people who can answer them already work for you.

Does your storefront calculate prices itself, or does it ask Sage 200 for every line?
Is the shop connected by direct SQL, the Sage 200 .NET SDK, or the Sage 200 REST API? If it's SQL, who holds the credentials?
How many of your stock codes are longer than 20 characters, and how many contain lower-case letters?
Do you sell ranges as separate stock items, and were those codes generated by an add-on such as Sicon Stock Matrix?
Does the storefront keep its own copy of order history, or does it read it live from Sage 200?

Frequently asked questions

Can I migrate from Sage 200 to Business Central with a Microsoft migration tool?

No. Microsoft's 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. There is no Sage 200 data migration extension, unlike QuickBooks Desktop and QuickBooks Online, which both have one. A Sage 200 to Business Central move uses configuration packages for master data plus bespoke work for everything else.

Is Sage 200 end of life?

No. Sage publishes end of support dates for versions on a latest-minus-two basis and reserves the right to change them, and it publishes no end of life date for Sage 200 as a product. Once a version has been out of support for 24 months you can no longer buy users for it, but the software keeps running. Dynamics AX customers face the opposite situation, because those end of support dates were published years in advance and did not move.

Does Sage 200 have product variants like Business Central?

No. Sage 200 has no native variant or matrix concept, so ranges are built as separate stock items, often generated by an add-on such as Sicon Stock Matrix. Business Central models a range as one item with a 20-character number plus Item Variant records with a 10-character code, so the migration has to collapse many Sage 200 stock items into one item with variants.

How long can a Sage 200 stock code be, and will it fit in Business Central?

A Sage 200 stock item code is up to 30 characters and a Business Central item `No.` is 20 characters, so codes over 20 characters have to be shortened. Business Central's `Code` data type also converts to uppercase and trims spaces, so mixed-case codes change too. Customer accounts go the other way, because a Sage 200 customer account reference is only 8 characters.

Can my web shop keep using direct SQL against the database after moving to Business Central?

No. Business Central online exposes no database, and Microsoft states that the only supported way to read data from Business Central online is through the API. Sage's own knowledge base already says that direct changes to the Sage 200 database are not supported under the end user licence agreement, so the SQL integration was never a supported asset in the first place.

Is the Sage 200 REST API good enough to run a web shop on?

It depends on the shop, and there are documented limits to plan around. Initial authentication needs a human via Sage ID, refresh tokens last at most 90 days before someone has to log in again, queries cap at 5,000 records, and Sage states it will not advise on endpoint usage or resolve errors in custom integrations once the API is enabled. Many Sage 200 shops use middleware such as Codeless Platforms BPA Platform or Zynk for exactly that reason.

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

Yes, if the storefront stays, because Sage 200 has no concept of a web user and the credentials live in the storefront's own identity store. What can break is the link between the login and the customer account, if customer references are renumbered or recased during the migration.

What happens to order history in the web shop?

If the storefront keeps its own copy of orders, nothing changes. If it reads history live from Sage 200, the account page goes empty on cutover unless posted Sage 200 documents are deliberately migrated into Business Central, and no tool does that automatically.

Should I fix the Sage 200 web shop integration now, or wait for Business Central?

Wait, unless something is actually broken or the storefront platform has its own deadline. Money spent hardening a SQL job, an SDK integration or an API layer in the year before the ERP move is written off on go-live day. If Adobe Commerce or another platform deadline forces action first, keep the intervention thin and explicitly disposable.

Can I use Sana Commerce or Dynamicweb with Sage 200?

No. Neither lists a Sage connector, and both support Business Central. This is one of the few places where moving off Sage 200 opens up options rather than closing them, because a whole class of Dynamics-native B2B storefront becomes available.

How to handle ecommerce when you migrate from Sage 200 to Business Central