How to handle ecommerce when you migrate from Sage 50 Accounts to Business Central

Short answer.

The answers usually point clearly at Abakion B2B Ecommerce, at Shopify, or at keeping the storefront and mid-tier you already have, and knowing which one you're facing is worth more than assuming the current split is the one to keep.

In most Sage 50 Accounts businesses the web shop doesn't depend on Sage 50 at all, because a mid-tier system such as Linnworks, Cloud Commerce Pro or Brightpearl holds the stock, the orders and often the pricing, and Sage 50 receives the accounting. So a move to Business Central rarely breaks the storefront, and instead forces a decision nobody has had to make: whether Business Central becomes the system of record. Sage 50 Accounts is also not on Microsoft's list of supported cloud migration sources, and because its data lives in a company data directory reached through the Sage client rather than in a SQL database, Microsoft's new any-SQL migration route doesn't reach it either.

Two routes make Business Central the source of truth: move B2C to Shopify with Microsoft's Shopify Connector, or move B2B into Business Central with Abakion B2B Ecommerce. Keeping the storefront and the mid-tier and rebuilding only the accounting link is the third route, and for a Sage 50 business it is often the smallest change.

A note on scope before anything else. This is about UK and Irish Sage 50 Accounts, the product that runs back through Sage Line 50 to Sage Sterling. The American product called Sage 50 is the former Peachtree, a different codebase with different behaviour, and nothing here describes it.

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

There are three real options for ecommerce when you migrate from Sage 50 Accounts to Business Central, and for a Sage 50 Accounts business the first one is a more reasonable answer than it is elsewhere in this series.

1. Keep the storefront and the mid-tier, and rebuild only the accounting connection as an API integration. It's often the smallest possible change. It's also the option that leaves your architecture exactly as it is, with the stock and the orders and the customer relationships living outside your ERP, and it's worth asking whether that's what you want on the other side of a migration, since it's the arrangement Sage 50's limits forced on you rather than one you chose.
2. Move B2C to Shopify and use Microsoft's Shopify Connector.
3. Move B2B into Business Central with the Abakion B2B Ecommerce app.

The other two make Business Central the system of record, and they split by who you sell to.

Is Sage 50 Accounts end of life?

No. Sage is still building on Sage 50 Accounts, with Copilot, expenses and Making Tax Digital compliance features in recent releases, and its published advice to a growing business is to grow inside the product by adding users, unlocking features and adding companies.

Two things usually bring a company to this decision anyway.

The first is the functional ceiling, and it's worth being specific about where that ceiling sits, because for an ecommerce business it's lower than people expect:

• Sales order processing is a Sage 50 Accounts Professional feature.
• There are no product variants at all.
• There's no multi-warehouse model in any tier, because location on the stock record is a text field rather than a location entity, so there are no per-location quantities to read.
• Stock categories are a two-digit number, so there are fewer than a hundred of them and they're flat.
• Both Standard and Professional are sold with two users included.

The second is Sage's own cloud path, and this is the part that changes the conversation.

What does Sage 50 Cloud Accounts mean for my web shop integration?

It removes the integration surface, at least initially. Sage 50 Cloud Accounts is the desktop product delivered from a hosted virtual machine, and it's in early adopter phase.

Sage's own FAQ says three things that matter here. You need to be on v34 to move. Once you upgrade your company to the cloud, your desktop company becomes read only. And on third-party integrations, Sage's answer is that they're not there yet but firmly on the radar, with no list of apps and no dates, while ODBC and Excel-based reporting won't be in the initial release either.

So the vendor's own cloud route arrives without the integration surface your web shop is using today. That isn't a criticism, it's a roadmap in progress. But it means "we'll just move Sage 50 to the cloud" doesn't answer the question this article is about.

Your accounts migrate. The question is what your web shop has been using instead.

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 Sage 50 Accounts really the source of truth for my web shop?

Usually not, and that's the difference between this article and the rest of the series.

If you sell online at any volume, there's almost certainly a layer between the shop and Sage 50 Accounts. In the UK that's usually Linnworks, Cloud Commerce Pro, Brightpearl or Mintsoft, and that layer holds the stock, the orders, the fulfilment state and often the pricing. Sage 50 Accounts receives the accounting.

You can see it in what those vendors say about themselves. Cloud Commerce Pro describes bringing orders, stock, fulfilment and sales channels into one connected system. And Linnworks, which is the single most common mid-tier in this segment, publishes an integration directory that lists marketplaces, webstores, 3PL and shipping partners, and under accounting lists QuickBooks Online and nothing else. There's no Linnworks page for Sage 50 and none for Business Central, because the accounting connection is somebody else's middleware.

So the honest version of your situation is probably this: your web shop doesn't depend on Sage 50 Accounts, it depends on the mid-tier, and the mid-tier posts to Sage 50 Accounts.

There's a real exception, and it's the B2B trade counter pattern. If you run a live B2B shop with GOb2b or something like it, orders land in sales order processing and are allocated, and the storefront reads live stock levels and due-in dates from the accounts. That requires Sage 50 Accounts Professional, because it requires sales orders, and for that cohort Sage 50 genuinely is the source of truth. If that's you, the good news is that GOb2b also supports Business Central, so the storefront can follow you across.

Is there a migration tool from Sage 50 Accounts to Business Central?

No. Sage isn't on Microsoft's list of supported cloud migration sources, which covers Business Central on-premises, Dynamics NAV, Dynamics GP 2015 and later, Dynamics SL 2015 and later, and any other SQL source using custom migrations. QuickBooks gets dedicated first-party migration extensions for both Desktop and Online. Sage isn't mentioned anywhere in Microsoft's migration documentation.

Microsoft added a Generic Custom migration type in 2026 release wave 1, GA on 1 April 2026, letting partners build reusable migration engines through a standardised AL interface. Microsoft's wording is that custom migrations let you migrate data from any SQL-based source. Sage 50 Accounts data lives in a company data directory reached through the Sage client rather than in a SQL database, so that route doesn't reach it.

Microsoft's own documented advice for non-SQL sources is the long way round: use configuration packages and templates to load Business Central on-premises, then use the cloud migration tool to move online. In practice, for Sage 50 Accounts, that means spreadsheets.

Worth noting what even a supported accounting migration carries, because it sets expectations. The QuickBooks extensions bring customers, vendors, items, chart of accounts, opening balances, on-hand quantities and open documents, and Microsoft states plainly that purchase orders and sales orders aren't migrated. Nobody's tooling moves your order history.

Does Sage 50 Accounts have an API my web shop can use?

No. There's no REST API for Sage 50 Accounts. Integration happens locally, through Sage 50 Accounts Data Objects over COM and through the Sage 50 ODBC driver, on a machine that has the Sage client installed and can reach the data directory.

Writes go through Sage 50 Accounts Data Objects, the COM object layer. It needs a Sage 50 client installed on the machine doing the integrating, it needs the right 32-bit or 64-bit build, and it needs a Sage login. Middleware vendors recommend creating a separate Sage user for the integration specifically so it isn't already logged in when the integration tries to connect, and the two commonest failure modes are exactly what you'd expect: a username already in use, and an exclusive mode error when any Sage user is in an exclusive area, which usually means somebody is running a backup. The remedy is to wait.

Reads come over the Sage 50 ODBC driver, which defines the queryable schema, with the object layer used as the escape hatch for fields ODBC can't see.

The Sage Accounting API is a different product. The API on Sage's developer portal belongs to Sage Accounting, not Sage 50 Accounts, and middleware vendors treat the two as entirely separate connectors. Remote Data Access is a way for Sage 50 clients to share data remotely rather than a channel for integration traffic, and it's a known cause of stuck integration logins.

Business Central is a different animal in exactly one respect that matters: there's nothing local. For Business Central online, in Microsoft's words, the only supported option for reading data is using APIs. No client on a server, no data folder, no shared login, and nothing that stops working because somebody started a backup.

Your web shop currently posts to your accounts through a COM object that shares a login with whoever is running the backup.

Do product codes and customer references change when I move from Sage 50 Accounts to Business Central?

Product codes may have to change, because Sage 50 Accounts allows 30 characters and Business Central's item `No.` is 20. Customer references get more room, because a Sage 50 account reference is 8 characters and Business Central gives you 20.

On a web shop those product codes are the SKU your customers see, often part of the product URL, and always the key your marketplace listings and your customers' saved reorder lists match on. So a shortening exercise in the accounts is a redirect exercise on the website.

Casing is the quieter one. Business Central's `Code` data type converts to uppercase and strips leading and trailing spaces, so `ab-100 ` and `AB-100` become the same thing. If your catalogue has codes that differ only by case or by a trailing space, they collide silently.

The catch on customer references is that 8 characters is why so many Sage 50 estates renumber during migration, and every renumbered account breaks the shop's stored link to the ERP customer even though the field got wider.

What does Sage 50 Accounts not have that Business Central does?

Three absences, and they're the reason this migration is an opportunity rather than a salvage job.

No product variants. In Sage 50 Accounts the item is the SKU, so a size and colour range exists as separate stock records. Business Central models it as one item with a `Code[20]` number plus Item Variant records with a `Code[10]` code, so somebody has to decide which of your stock records were ever really separate products.

No locations. Location on the Sage 50 stock record is a text field, there's no location table and no per-location quantity. So there's nothing to migrate into Business Central's locations, and location design becomes a greenfield decision inside the project. Your shop's availability logic gets rebuilt on top of whatever you choose.

No product content. There's a description, a web description, a longer details field, a two-digit numeric category, a publish-to-web flag and three custom fields. No images, no attributes, no hierarchy, no SEO fields, no per-channel content. Business Central has item attributes, typed and inherited through item categories, which Microsoft's documentation names as search terms for customers in integrated web shops, plus extended text and marketing text.

In Sage 50 Accounts, a stock category is a two-digit number. On your web shop it's a navigation menu.

How do Sage 50 price lists map to Business Central price lists?

Most of the structure maps, but Sage 50 price list lines can hold derivation rules rather than prices, and Business Central price lists hold resolved numbers only.

A Sage 50 Accounts price list is a header plus product lines keyed to customers, and it comes in three shapes: a customer price list, customer special prices, and supplier prices. A line's discount type can be fixed, standard, a percentage decrease, a value decrease, or a markup on cost, on sales price or by value, with the resolved figure stored alongside it. Customer-level pricing sits on the customer record as a fixed discount, a discount type and a single-character discount band. And per-customer pricing is a Sage 50 Accounts Professional feature.

Business Central has price lists with an applies-to type and number, so a list applies to a customer or a customer price group, with unit of measure, minimum quantity, currency and dates on the line. Its rule is that the best price is the lowest price with the highest line discount allowed on a given date.

Three things to plan for:

• Every mark-up-cost-by-twelve-percent line has to be resolved to a number at migration, and then somebody has to decide who recalculates it afterwards.
• The single-character discount band has no direct equivalent, and the nearest thing, a customer price group, works at a different granularity.
• Sage 50's price lists and special prices are two mechanisms that both collapse into Business Central price lists, so precedence has to be re-decided rather than carried across.

If you're on Sage 50 Accounts Standard, none of that is where your B2B pricing lives, because Standard doesn't have per-customer pricing. It lives in the shop or the mid-tier, which is the same point as before arriving from a different direction.

And if Shopify is on your shortlist, there's a hard limit to know now rather than later. Microsoft documents that the connector calculates a price by creating a temporary sales quote at a quantity of one, so only prices and discounts applicable at quantity one are used, and you can't export different prices or discounts based on quantity. If your customers get volume breaks, that sentence decides the architecture on its own.

Why does stock availability behave differently in Business Central?

Because Sage 50 Accounts hands over three numbers and Business Central computes an answer.

Sage 50 Accounts gives an integration quantity in stock, quantity allocated and quantity on order, and free stock is a subtraction rather than a stored field. Allocation only means something if you have sales orders, which is a Professional feature, so on Standard there's no order document behind the allocated figure at all.

Business Central computes availability across inventory, reservations and outstanding documents, with views by event, period, location and variant. The date version of the question, when can the customer actually have it, comes from order promising, which is an action a person runs on selected sales lines and accepts rather than an endpoint a storefront calls. What the Shopify Connector publishes is one of two calculations, projected available balance at today or free inventory not reserved.

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

Both survive, because neither was in Sage 50 Accounts. What breaks is the key, if account references or product codes get renumbered.

On Sage 50 Accounts Standard there are no sales orders, so what you have is invoices, with no order status and no fulfilment state. Which means your shop's order history has almost certainly been coming from the shop or the mid-tier all along.

Customer logins are the same, and this is the genuinely reassuring part. Sage 50 Accounts has no concept of a web user, no password field, nothing. Logins live in the storefront, so they survive untouched. But if account references or product codes are renumbered on the way into Business Central, saved carts, reorder lists and invoice links stop resolving even though every record survived.

When does the Microsoft Shopify Connector fit?

When you sell to consumers, or to business customers whose pricing works at a single quantity tier, and you're selling through one storefront rather than several marketplaces.

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. Prices export at quantity one only, so volume breaks don't travel. A Shopify variant matrix combining two or more options can't be created by the connector, because Business Central has no option matrix. Marketing text is imported only for newly created items and doesn't update on later syncs, rule-based smart collections aren't supported, and on image export new images replace previous ones with old ones deleted manually in Shopify Admin. Extension points are deliberately few, so Microsoft can follow Shopify's release pace without breaking changes. It's one shop per configuration, so other marketplaces need something else. And you have to stay current on Business Central versions.

For a Sage 50 business selling on several marketplaces through a mid-tier, that last pair of sentences is the one to sit with, because it's the case where the mid-tier stays.

When does Abakion B2B Ecommerce fit?

When you sell to trade customers on their own prices and they reorder, which describes most Sage 50 Accounts wholesalers and distributors.

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 50 Accounts customer this is the whole game, because your product content has never had anywhere to live except the storefront, and this is the first time it could sit in the system that also knows the price and the stock.

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 50 customer. Today your customer's price might be in the shop, the stock is in the mid-tier, the invoice is in Sage 50 Accounts, and reconciliation is a job somebody does. With a storefront reading 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 accounts first, and the storefront once, afterwards. And check what Sage 50 Cloud Accounts does to your integration before you commit to that as an interim step.

The most expensive mistake available to you is spending money on the Sage 50 Accounts integration in the year before you replace Sage 50 Accounts. Every hour spent nursing the object layer, or working around a locked data file, is 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.

There's a Sage 50 specific trap in the sequencing, and it deserves naming. If you're being nudged towards Sage 50 Cloud Accounts, be clear about what that does to the integration first, because Sage's own FAQ says third-party app integrations aren't there yet and ODBC won't be in the initial release, and that once your company moves to the cloud the desktop company becomes read only. Moving your accounts to a hosted desktop and then discovering the shop can't reach them is the same two-project outcome by a different route.

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
• need volume break pricing published to a Shopify catalogue

The multichannel case is the one that catches Sage 50 Accounts businesses most often, because selling on Amazon and eBay and your own site through a single mid-tier is common in this segment and it's exactly what one shop per configuration doesn't cover. If that's you, the realistic answer is that the mid-tier stays and Business Central becomes the financial and stock backbone underneath it, which is a smaller change than this article's other two routes and a perfectly respectable outcome.

But plenty of companies assume they're in that group without testing it, keep three systems in sync by hand, and never find out that most of what the mid-tier was doing was compensating for the accounting package.

Where to start

Five questions, and you can answer all of them this week.

1. What actually holds your stock and your orders today: the shop, a mid-tier, or Sage 50 Accounts?
2. Are you on Standard or Professional? That decides whether you have sales orders and per-customer pricing at all.
3. How many of your product codes are longer than 20 characters, and do any of them differ only by case?
4. Do your customers get volume break pricing, and where is it held?
5. Would you rather Business Central became your system of record, or would you rather keep the mid-tier? Both are valid, and the answer changes everything downstream.

The answers usually point clearly at Abakion B2B Ecommerce, at Shopify, or at keeping the storefront and mid-tier you already have, and knowing which one you're facing is worth more than assuming the current split is the one to keep.

Frequently asked questions

Both apps are on Microsoft Marketplace

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

Sources

• Sage 50 Accounts, Sage UK
• Sage 50 Accounts, Sage Ireland
• Sage 50 Cloud Accounts frequently asked questions, functionality, Sage Community Hub
• Sage 50 Cloud Accounts frequently asked questions, third-party integration and apps, Sage Community Hub
• Your Sage 50 Accounts software can grow with you, Sage Community Hub
• Get more from Sage 50, Sage UK
• Sage 50 UK connector documentation, Zynk
• Sage 50 UK stock record schema, Zynk developer documentation
• Sage 50 UK customer schema, Zynk developer documentation
• Sage 50 UK price list schema, Zynk developer documentation
• Sage 50 UK connection and troubleshooting, Zynk
• Sage 50 integration requirements, Codat
• GOb2b for Sage 50, GOb2b
• Linnworks integrations directory, Linnworks
• Cloud Commerce Pro, Cloud Commerce Pro
• Migrate on-premises data to Business Central online, Microsoft Learn
• Custom migrations to Business Central online, Microsoft Learn
• Migrate to the cloud from any SQL database, 2026 release wave 1, Microsoft Learn
• QuickBooks Desktop data migration extension, Microsoft Learn
• Item table reference, Business Central, Microsoft Learn
• Item Variant table reference, Business Central, Microsoft Learn
• Location table reference, Business Central, Microsoft Learn
• Code data type, Business Central, Microsoft Learn
• Record sales price, discount and payment agreements, Microsoft Learn
• Calculate order promising dates, Microsoft Learn
• Work with item attributes, Microsoft Learn
• Synchronise items with Shopify, Microsoft Learn
• Get started with the Shopify Connector, Microsoft Learn
• Installing and uninstalling extensions in Business Central, Microsoft Learn