Moving ecommerce: Sage 100 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 can simply be pointed at a new system.

A Sage 100 web store integration cannot be moved to Business Central, because it reads Sage 100 over a read-only ProvideX ODBC driver and writes back through the Business Object Interface over COM, and Business Central online exposes neither a database nor a COM interface. Sage 100 is also not on Microsoft's list of supported cloud migration sources, and Microsoft's new any-SQL migration route only reaches Sage 100 Premium, because Sage 100 Standard and Sage 100 Advanced store data in ProvideX rather than SQL Server.

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.

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

There are three real options for ecommerce when you migrate from Sage 100 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 and the connector vendor supports both ends. But two of the largest Sage 100 connector vendors have no Business Central product at all, so check that before you assume continuity. And 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.
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 synchronized 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 catalog	No, the storefront reads Business Central directly
Pricing source	Whatever you build	Business Central prices synchronized to Shopify	Business Central, live, including customer agreements
Availability	Whatever you build	Inventory synchronized 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
US sales tax	Avalara behind Business Central	Shopify Tax at checkout plus Avalara behind Business Central	Avalara behind 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 store	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

Is Sage 100 end of life?

No. Sage 100 has no published end-of-life date, and that's worth saying plainly, because a lot of the noise around this decision assumes there is one.

What Sage does publish is a rolling support window: the current version and two previous versions. Retirement is mechanical rather than calendar-based, so version 2023 retired when Sage 100 2026 shipped in April 2026, and 2024 will retire when 2027 ships. That gives any given version about three years, and the software keeps running afterward.

So something else brought you here. Usually it's one of four things: your storefront platform has a deadline, the 2026 upgrade turned out to be 64-bit only, the person who wrote the integration has left, or you've outgrown what a ProvideX file system can do.

That last one deserves a moment, because it turns out to matter more than anything else in this article.

Sage 100 Standard and Sage 100 Advanced store data in ProvideX. Only Sage 100 Premium stores data in Microsoft SQL Server. Sage's own install guide states it as a table, and in April 2024 Sage renamed the perpetual editions to put the data layer in the product name: Sage 100 Advanced PVX Install, Sage 100 Premium SQL Install. Which edition you bought was a licensing decision somebody made years ago, and most finance teams don't know it was made.

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 anybody who needs connector apps, and we won't cover it.

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

No. Sage 100 isn't on Microsoft's list of supported cloud migration sources, which covers Business Central on-premises, Dynamics NAV, Dynamics GP 2015 and later, and Dynamics SL 2015 and later. QuickBooks gets dedicated data migration extensions for both Desktop and Online. Sage isn't mentioned anywhere in Microsoft's migration documentation.

There is something new, though, and it's the one place where your Sage 100 edition decides your options. In 2026 release wave 1, Microsoft added a Generic Custom migration type to the cloud migration wizard, designed for SQL-based source systems, with a standardized AL interface so partners can build reusable migration engines and ship them on Microsoft Marketplace. It went GA on April 1, 2026.

Sage 100 Premium is a SQL Server database. Sage 100 Advanced is a folder of files. Microsoft's migration tool can only read one of those.

For everybody else, the migration is a data project: master data, opening balances and setup, loaded through configuration packages or a custom build. Posted invoice history doesn't come along by itself, and neither do item images, because blob fields can't move through Excel-based configuration packages at all.

Does the Business Object Interface work with Business Central?

No. The Sage 100 Business Object Interface is a Component Object Model interface that runs locally against the ProvideX runtime and the MAS90 path, and Business Central online has no COM surface and no database to read, so both halves of a Sage 100 integration have to be rewritten as API calls.

This is the part that makes Sage 100 different from every other system in this series, and it isn't a matter of your integration being badly built. Your integration was built exactly the way Sage documents, and none of it can travel.

Reads come over ODBC. The DSN is `SOTAMAS90` and the driver is the ProvideX ODBC Driver. Sage's own knowledge base frames it purely as an export channel: you can export data from Sage 100 using internal applications or external ODBC-compliant programs. Sage never documents ODBC writes, and the practical consensus, stated repeatedly in Sage's own community by Sage staff, is that none of the ODBC drivers shipped with Sage 100 are read/write, because writing that way would bypass the business objects and compromise the audit integrity of the data.

Writes come over COM. The Business Object Interface is provided as part of your Sage 100 activation and gives access to Sage 100 through the Component Object Model. It needs the Sage 100 client components and the ProvideX runtime on the calling machine, plus access to the MAS90 path. And it needs ProvideX even on Sage 100 Premium, which is why the canonical Premium error message is a failure to initialize the ProvideX library.

Sage won't help with the code you write against either one. Sage states that it cannot troubleshoot, debug or assist with the design of programs not written by Sage developers, and limits Business Object Interface support to people who have completed the object interface course.

And eBusiness Web Services is narrower than people expect. It's SOAP, and its complete operation list gets, creates, updates and deletes sales orders, customers and customer contacts, adds a card to the vault and preauthorizes a card. There are no item, inventory, price, warehouse or shipment operations at all.

Sage 100's own web service can create an order and create a customer. It can't tell you the price of anything, or whether you have it in stock.

So every real Sage 100 storefront integration is a hybrid: read over ODBC or SQL, write over COM, and fill the gaps with polling, because none of it has change notification. Two technologies, one of them 32-bit COM, and Business Central online has a port for neither. In Microsoft's words, the only supported option for reading data from Business Central online is using APIs.

And Sage has been narrowing that surface rather than widening it. SData, the one HTTP-shaped data feed Sage ever offered for Sage 100, was deprecated effective the 2025.0 release. Sage 100 2025 removed the optional 64-bit ODBC driver installation. Sage 100 2026 is 64-bit only. Third parties now sell REST layers over the Business Object Interface, from Kissinger and Greytrix among others, precisely because Sage doesn't.

Sage spent 2025 removing the 64-bit ODBC driver and 2026 going 64-bit only, so the integration surface got narrower at exactly the moment its customers needed an HTTP one.

What happens if my store is eBusiness Manager?

You lose the store, not just the integration, because eBusiness Manager keeps the web logins, the live shopping carts, the category tree and the web copy inside Sage 100 modules.

eBusiness Manager is Sage's own web store module, and it's still shipping, with an installation guide dated April 2026. Architecturally it's an application server, a Web Engine written in ProvideX listening on a TCP port, and Microsoft IIS with an ISAPI plug-in that redirects to the Web Engine. The two applets are `.order` for existing-customer B2B ordering and `.store` for B2C. It runs on Sage 100 Standard and Sage 100 Advanced only, and Sage's own FAQ says outright that those FAQs don't apply to Sage 100 Premium, so Sage never brought its web store to its own SQL edition. Sage's platform matrix still carries a warning against running the Web Engine as a service because of issues involving credit card processing, and that warning has been carried forward for years.

Here's what matters for the migration:

Web logins live in Sage 100. Customers are flagged Internet Enabled in Customer Maintenance, and web users are defined in the eBusiness Manager module's own User ID Maintenance, where Sage states that user IDs correspond to `.order` and `.store` customers.
Live shopping carts are Sage 100 records, with a retention setting in the module's options.
The category tree is a Sage 100 table with a ten-character category code and a thirty-character image filename.
The web copy is a fifty-character web name and a 4,096-character long description in a side table.
The storefront itself is around fifty editable HTML merge templates on the web server.
Stored credit card tokens sit behind the module's vault and preauthorization functions.

Business Central has no B2B web-customer login concept to receive any of that, so an eBusiness Manager site is a rebuild rather than a migration.

Do item codes and customer numbers change when I move from Sage 100 to Business Central?

Item codes change only if somebody expanded them years ago, and customer numbers change for everybody, because Sage 100's customer key is composite and Business Central's is a single field.

A Sage 100 item code defaults to fifteen characters and can be expanded to thirty with the Allow Entry of Expanded Item Codes option in Common Information Options, which Sage warns is irreversible once accepted. In Business Central, an item's `No.` is `Code[20]`. So if nobody ever turned expansion on, your codes fit comfortably. If somebody did, some of them don't, and every code that has to change is a URL on your storefront that has to redirect.

Customer identity changes shape whether you like it or not. The Sage 100 AR_Customer key is a two-character division number plus a customer number, and Business Central's customer `No.` is a single `Code[20]`. Sage's own documentation is inconsistent about how long the customer number itself can be, with the data dictionary saying twenty and the entry screen documentation saying nine when divisions are enabled, so treat that as something to check in your own data. Either way, the migration has to concatenate, and `02ACME00001` isn't the string your web store has been sending for a decade.

One thing Sage 100 customers get off easy on. Business Central's `Code` data type converts to uppercase and strips leading and trailing spaces, which is a real problem for systems with mixed-case SKUs. Sage 100 item codes are conventionally uppercase already, so this mostly doesn't bite.

Two things that do:

Sage 100 has alias item numbers, which are vendor or customer part numbers mapped many-to-one against an inventory item. If your web store or your EDI feed matches on those, that's a mapping table nobody remembers to migrate. Business Central's equivalent is item references.
Sage 100 has no native product variants, so if you sell size and color you're running an ISV matrix module and your ranges exist as individual item codes. Business Central models the same range as one item with a `Code[20]` number plus Item Variant records with a `Code[10]` code, so the migration has to decide whether those were ever really separate products.

How does Sage 100 pricing map to Business Central pricing?

It doesn't map one to one, because Sage 100 walks a ranked hierarchy and stops at the first hit, while Business Central evaluates all applicable agreements and picks the best price.

Sage publishes the Sage 100 hierarchy, highest priority first:

Sales promotion, if a promotion covers the item and today's date and the promotion price is lower
Customer price schedule, which is contract pricing
Item pricing at the customer's price level
Item pricing at the standard or blank price level
Price code at the customer's price level
Price code at the standard or blank price level
Standard price from Item Maintenance

The mechanics are tighter than that description suggests. All of it lives in one table discriminated by a single character for price code, item price or item and customer price. There are exactly five pricing methods: cost markup amount, cost markup percent, price discount amount, price discount percent, and price override. And there are exactly five quantity break tiers, hard-coded as five columns.

Then there's the price level, which until very recently was one character.

A Sage 100 price level is one character. Everything your B2B customers pay is encoded in a single letter.

Sage 100 2026 expanded price levels from one character to fifteen, which is a genuine improvement and also a problem, because any web store that hardcoded those single characters just met a fifteen-character field.

Business Central defines best price as the lowest price with the highest line discount allowed on a given date, checking customer or customer price group, item or item discount group, minimum quantity, unit of measure and currency, and it inserts a currency-specific match even where local currency would give a better price.

Same data, different arithmetic. Three consequences worth checking against your own setup:

A Sage 100 customer who deliberately placed a higher price at a higher priority, a negotiated contract price that should beat a promotion, gets a different answer in Business Central, because Business Central doesn't stop at the first match.
Price override has no clean equivalent, because Sage's override says stop calculating and use this number, and Business Central's model has candidates and a comparison rather than a stop.
Five quantity break columns migrate into price list rows easily enough, but any web store reading `BreakQuantity1` through `BreakQuantity5` by column name has nothing left to read.

Which brings up the question worth answering first. If your web store 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 cart to the invoice.

Why does inventory availability behave differently in Business Central?

Because quantity available in Sage 100 is a configured formula and Business Central has no equivalent stored field.

Quantity available in Sage 100 is quantity on hand plus quantity on purchase order plus quantity on work order, minus quantity on sales order, back order and work order requirements. But which of those components count is a company-level configuration choice in Inventory Management Options, so two Sage 100 companies with identical stock can publish different availability to the same storefront.

In Sage 100, quantity available is a setting rather than a number.

Business Central has inventory per item, location and variant, availability views by event, period, location and variant, and reservation logic underneath. The date version of the question, when can the customer actually have it, is answered by order promising, which is an action a user runs on selected sales lines and accepts rather than an endpoint an integration calls.

Warehouses are three characters in Sage 100, and bin location is a single ten-character text label per item and warehouse, so if you have real bins you're running an ISV multi-bin module such as Scanco or DSD. Business Central's bins are a different model with real warehouse logic behind them.

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

It lives in your storefront today and always has, because the Sage 100 item record was never built to hold it, and Business Central holds more of it than Sage 100 does.

The Sage 100 item description is thirty characters, with extended descriptions in a separate Item Text Maintenance window. There are no item attributes, so extra fields are user-defined fields from Custom Office. Images were never in Sage 100 at all, because Sage 100 stores a filename and pixel dimensions and the file itself sits on an IIS server.

The Sage 100 item description is thirty characters. Your product page headline is longer than that.

So your catalog copy, your photography, your SEO and your merchandising taxonomy are in Shopify or BigCommerce or Adobe Commerce today, because there was never anywhere in Sage 100 to put them. Nothing to extract, which sounds like good news and isn't quite, because the content is locked inside the platform you may be replacing.

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

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

It depends entirely on which storefront you have. A third-party platform keeps its own logins and history, so they survive. eBusiness Manager keeps them inside Sage 100, so they don't.

If your store is Shopify, BigCommerce, Adobe Commerce or WooCommerce with its own customer accounts, logins and order history were never in Sage 100 and the ERP migration doesn't touch them. What breaks is the stored link between the web account and the ERP customer key, because that key changes shape when a division number and a customer number are concatenated into one field.

If your store is eBusiness Manager, the logins, the carts and the web content are Sage 100 module data and there's nothing in Business Central to receive them.

One piece of unambiguous good news for a US audience. Sage Sales Tax is Avalara, and Avalara publishes an AvaTax connector for Business Central. The tax engine is the one thing here that ports cleanly, same vendor at both ends.

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 catalogs.

Architecture. The Shopify Connector is built by Microsoft, ships preinstalled with Business Central online, and runs on the job queue with a dozen schedulable recurring activities. There's no middleware to license, 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 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. Fulfillment tracking goes back to Shopify, and posted sales invoices are exported.

Tax. Shopify Tax calculates sales tax at checkout for the US, and Avalara sits behind Business Central for posting and filing. Worth naming plainly: that's two tax engines, and they need to agree.

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 catalogs, and B2B company sync reached the Basic, Grow and Advanced plans on July 8, 2026, with up to three active market catalog assignments on those plans and unlimited on Plus, but 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 100 distributors and manufacturers.

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 synchronization job, no staging database, no integration to own, and nothing to regression test twice a year.

Data flow. Customer-specific catalogs, 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 100 customer that's the one place you have to invest, because your web copy and images are in the storefront and were never in the ERP.

Tax. Avalara is supported for US sales tax, which is the same engine you're using today.

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 store.

The argument that lands hardest for a Sage 100 customer. Today your store reads a ProvideX file system over a read-only ODBC driver and writes back through 32-bit COM. With a storefront that reads Business Central directly, there's nothing to push out to the store, because there's no out.

In what order should you sequence the two projects?

The ERP first, and the storefront once, afterward, unless the 64-bit upgrade or a storefront platform deadline forces action sooner.

The most expensive mistake available to you is spending money on the Sage 100 integration in the year before you replace Sage 100. Every hour spent nursing a COM script or an ODBC job 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.

Two things can force your hand earlier, and both deserve naming rather than waving away. Sage 100 2026 is 64-bit only, and a 64-bit install on the same server stops earlier 32-bit installs from functioning, so the upgrade that breaks your COM integration may already be scheduled. And if you're on Adobe Commerce, anything at 2.4.6 or below is out of regular support as of August 2026, and Magento 1 has been unsupported since June 2020. In either case the honest answer is a minimum intervention, 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 a COM integration nobody will support because of an assumption nobody checked.

Where to start

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

Which edition are you on: Sage 100 Standard, Advanced or Premium? That decides whether a SQL-based migration route exists at all.
Does your store calculate prices itself, or does it ask Sage 100 for every line?
Was Allow Entry of Expanded Item Codes ever turned on, and how many item codes are longer than twenty characters?
Does anything match on alias item numbers, and who maintains that table?
Is your storefront a third-party platform with its own customer accounts, or is it eBusiness Manager?

Frequently asked questions

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

No. Sage 100 isn't a supported cloud migration source, and there's no Sage data migration extension the way there is for QuickBooks Desktop and QuickBooks Online. Microsoft's 2026 release wave 1 Generic Custom migration type is designed for SQL-based sources, so it can potentially reach Sage 100 Premium, which runs on SQL Server, but not Sage 100 Standard or Advanced, which store data in ProvideX.

What's the difference between Sage 100 Standard, Advanced and Premium for a migration?

The data layer. Sage's own install guide describes Standard as stand-alone or LAN on ProvideX, Advanced as client/server on ProvideX, and Premium as client/server on Microsoft SQL Server. For a migration that difference decides whether any SQL-based tooling can see your data at all, which is why Sage renamed the perpetual editions in April 2024 to include PVX and SQL in the product name.

Does the Sage 100 Business Object Interface work with Business Central?

No. The Business Object Interface is a Component Object Model interface that requires the Sage 100 client components, the ProvideX runtime and access to the MAS90 path on the calling machine. Business Central online exposes no COM interface and no database, and Microsoft states that the only supported way to read data from Business Central online is through the API.

Can my web store read the Sage 100 database directly after we move?

No. Business Central online has no accessible database. Even today the ODBC route into Sage 100 is read-only in practice, and Sage documents it as an export channel rather than an integration surface, so writes already go through the Business Object Interface over COM.

Does Sage 100 have a REST API?

No. What Sage ships is eBusiness Web Services, which is SOAP, and its operations cover sales orders, customers, customer contacts and credit card vault functions only. There are no item, price, inventory or shipment operations. SData, the closest thing Sage 100 had to an HTTP data feed, was deprecated effective the 2025.0 release, and third parties now sell REST layers over the Business Object Interface.

Will my item codes fit in Business Central?

Usually yes, and it depends on one checkbox. A Sage 100 item code is fifteen characters by default and thirty if Allow Entry of Expanded Item Codes was ever turned on, which Sage says is irreversible. Business Central's item `No.` is twenty characters, so a shop that never expanded fits comfortably and a shop that did has codes to shorten. Dynamics AX customers face a harder version of this problem, because their variant identity has to be squeezed into a ten-character variant code.

What happens to eBusiness Manager when we move to Business Central?

It goes away, and it takes the store with it. eBusiness Manager keeps web logins in its own User ID Maintenance, live shopping carts as Sage 100 records, the category tree in a Sage 100 table and the web copy in a side table plus HTML templates on the web server. Business Central has no equivalent module, so an eBusiness Manager site is rebuilt rather than migrated.

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

Yes, if your storefront is a third-party platform with its own accounts, because those credentials were never in Sage 100. What can break is the stored link between the web account and the ERP customer, since Sage 100's division-plus-customer key becomes a single field in Business Central. If your storefront is eBusiness Manager, the logins are Sage 100 data and don't survive.

What do we do about US sales tax in Business Central?

Keep Avalara. Sage Sales Tax is Avalara, and Avalara publishes an AvaTax connector for Business Central on Microsoft Marketplace, so the tax engine is the same vendor at both ends. If you also run Shopify, note that Shopify Tax calculates at checkout, which means two engines that need to agree.

Should we fix the Sage 100 integration now, or wait for Business Central?

Wait, unless something is actually broken or a deadline forces it. Money spent nursing a COM script or an ODBC job in the year before the ERP move is written off on go-live day. Two things can force it: Sage 100 2026 is 64-bit only, and a 64-bit install stops earlier 32-bit installs on the same server from functioning; and Adobe Commerce 2.4.6 and below are out of regular support as of August 2026.

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