Dynamics NAV to Business Central Migration: What Happens to Your WooCommerce Integration

A Dynamics NAV to Business Central migration moves your ERP data and customizations to Microsoft’s cloud platform, but it does not carry your WooCommerce connector with it. NAV connectors rely on NAV-specific APIs that Business Central does not support, so a new ecommerce integration has to be built and timed to your go-live date.
If you run WooCommerce on top of Dynamics NAV, you have probably already started planning the move to Business Central. Your Microsoft partner has a project plan. Finance knows what’s coming. What often gets missed is the one piece that keeps orders, stock and customer data flowing into your store every day: the ecommerce connector.

That gap is the subject of this guide. Not the finance migration, not the general reasons to upgrade, but the specific question store owners ask once they realize their ecommerce integration was never part of the ERP project scope.

A typical version of this story: a mid-size distributor running WooCommerce on top of NAV 2016 kicks off a Business Central migration with their Microsoft partner. Finance, inventory and reporting all get scoped and tested. Nobody on either side raises the ecommerce connector, because the ERP partner assumes it’s the store’s responsibility and the store assumes it’s part of the migration. It surfaces two weeks before go-live, when someone finally asks what happens to order sync. By then, there’s no time left to build and test a replacement properly.

What Is a Dynamics NAV to Business Central Migration?

A Dynamics NAV to Business Central migration is the process of moving a company’s data, customizations and business logic from Microsoft Dynamics NAV (the on-premise ERP formerly known as Navision) to Dynamics 365 Business Central, its cloud-based successor. Microsoft outlines the technical steps across six phases, covering everything from initial assessment through post-migration follow-up. The two phases that matter most for your ecommerce integration are the Business Central upgrade, where customizations get converted into AL extensions, and the data migration itself.

For most companies this is primarily an ERP and finance project. IT documents the current NAV version and every custom object. A Business Central partner assesses which customizations can be rebuilt, which have a ready-made replacement on Microsoft AppSource, and which can simply be retired because Business Central already does that job natively.

Ecommerce rarely shows up on that list. It’s not because anyone forgot on purpose. Business Central migrations are scoped around finance, inventory and operations, and a Microsoft partner’s job is to get those systems running correctly. The storefront sits one layer outside that scope, connected through a piece of middleware that nobody on the migration team is specifically responsible for.

Most companies going through this are small to mid-size businesses that adopted NAV years ago, often on version 2016, 2017 or 2018, and are only migrating now because support deadlines forced the decision. They tend to have accumulated years of customizations, and the ecommerce connector is usually one of the oldest and least documented pieces in the stack. Nobody currently on staff necessarily remembers exactly how it was built.

Why Your WooCommerce Connector Stops Working

Here’s the part that catches people off guard. Most WooCommerce connectors built for Dynamics NAV talk to NAV through NAV-specific web services and, in many older builds, a web service access key over basic authentication. Business Central online does not accept that authentication method. It requires OAuth 2.0 through a Microsoft Entra ID app registration, and its API structure, endpoint names and data model are different enough that the old connection simply has nothing to talk to on the other end.

So when NAV goes away, the connector doesn’t degrade gracefully. It stops. Orders placed on your WooCommerce store stop reaching the ERP. Stock levels stop updating. Whatever worked the day before go-live does not work the day after, unless someone has already rebuilt it.

The Data Model Isn’t a Straight Swap Either

Even once a connection exists, field mapping has to be redone. Item numbers, inventory locations, customer records and posting groups are structured differently in Business Central than they were in NAV. A connector that just points the old field mappings at new API endpoints will produce sync errors, or worse, silently wrong data. Someone who understands both the old NAV setup and the new Business Central structure needs to rebuild that mapping by hand.

Dynamics NAV vs Business Central: What Changes for Ecommerce

Aspect	Dynamics NAV	Business Central
Deployment	On-premise, your own servers	Cloud (SaaS), or on-premise if required
Authentication	Web service access keys, basic auth	OAuth 2.0 via Microsoft Entra ID
Customization code	C/AL	AL, built as extensions
API structure	NAV-specific web services	REST API v2.0 and OData v4
Ecommerce connector compatibility	Built for NAV endpoints	Requires a new or rebuilt connector
Updates	Manual, version-based	Continuous, twice-yearly releases

The authentication row is the one that breaks connectors outright. The API structure row is the one that breaks field mapping. Both need to be solved before your store can talk to Business Central at all.

What a NAV to Business Central Migration Actually Involves

A typical migration, from the ecommerce side looking in, follows this sequence:

• Assessment. The Business Central partner catalogues your NAV version, active modules, customizations, and integrations, including anything connecting to WooCommerce.
• Customization conversion. Custom C/AL code gets converted to AL extensions, replaced with a Microsoft AppSource app, or retired if Business Central already covers it.
• Data migration. Master data such as items, customers and open transactions move across, cleaned and validated along the way.
• Ecommerce connector rebuild. A new integration is built against Business Central’s REST API, with OAuth authentication and updated field mapping. This step is rarely on the ERP partner’s task list, which is why it needs a separate owner.
• Parallel testing. Test orders run through the new connector against a Business Central sandbox before anything goes live, covering guest checkouts, variable products, discounts and refunds.
• Cutover. ERP and ecommerce switch together, ideally on the same date, so there’s no window where orders are landing in a system nobody is watching.

Skipping step 4 as its own workstream is the most common reason ecommerce breaks during a migration that otherwise goes smoothly.

Who Handles Your Ecommerce Integration During the Migration?

This is the question that matters most, and it’s the one nobody asks until it’s almost too late.

Your Business Central implementation partner is not responsible for your ecommerce integration unless you have explicitly written it into the project scope. Their contract covers finance, inventory and operations on the ERP side. That’s a reasonable boundary. Building and testing a WooCommerce connector is a different skill set from configuring general ledger posting groups, and most ERP partners will say so directly if you ask.

Your existing ecommerce agency, the one that may have built your original NAV connector, often doesn’t know Business Central’s API well enough to rebuild it from scratch either. They know your store. They don’t necessarily know OAuth app registrations or Business Central’s entity structure.

That leaves a gap between two specialists, each correctly staying inside their own lane. Someone needs to own the ecommerce side specifically, brought in early enough to build and test against your actual Business Central environment before your go-live date, not after.
Practically, that means asking your Business Central partner one direct question early in planning: is ecommerce integration in scope, or is that on us to solve separately? Get the answer in writing before the project timeline is locked.

Common Mistakes When Migrating an Ecommerce Store from NAV to Business Central

Assuming the old connector will “just work.” It won’t. The authentication method alone rules that out.

Leaving ecommerce out of the project timeline. If the connector rebuild isn’t scheduled alongside the ERP work, it becomes a scramble in the final weeks before go-live.

Reusing old field mappings without review. Business Central’s data model is close enough to NAV’s to look familiar and different enough to cause quiet errors if you copy mappings across unchanged.

Testing only with clean, simple orders. Guest checkouts, partial refunds and discounted bulk orders are where sync issues actually surface. Test with the messy cases, not just the easy ones.

Not confirming who owns post-launch fixes. Decide in advance whether the ERP partner, the ecommerce team, or an outside integration specialist handles issues that show up in the first weeks after cutover.

Waiting for a support deadline to force the decision. Some businesses only start planning once a NAV version reaches end of support and security patches stop. By then, the migration timeline is compressed, and the ecommerce piece is the first thing to get rushed. Starting the assessment before the deadline hits gives the connector rebuild room to be done properly instead of urgently.

Underestimating how different the two data models are. It’s tempting to assume Business Central is just a newer version of NAV with the same structure underneath. The core concepts carry over, but item, customer and posting group records are organized differently enough that a direct copy of old logic causes problems that don’t show up until real orders start flowing through.

How Long Does It Take, and What Does It Cost?

The ERP side of a NAV to Business Central migration commonly runs eight to twenty weeks, though estimates vary by partner and how customized your NAV instance is. The ecommerce connector rebuild can often run in parallel, and in our experience usually needs two to six weeks depending on your catalog complexity and how many custom fields your store uses.
Cost for the ecommerce piece varies with scope. A store with a standard catalog and no unusual workflows costs less to reconnect than one with multi-currency pricing, customer-specific catalogs, or a multi-warehouse fulfillment setup. If you want a sense of what an ongoing connector runs once it’s live, our connector pricing page breaks down what drives the cost.

Budget for the rebuild as its own line item in the migration project, separate from the ERP implementation cost. Treating it as an afterthought is how it ends up unbudgeted and unbuilt when go-live arrives.

Three factors drive the actual cost more than anything else: how many custom fields your current connector maps, whether you run one store or several against the same Business Central tenant, and how much testing time you build in before cutover. A single-store setup with a standard catalog is the cheapest and fastest to reconnect. Multi-currency pricing, customer-specific wholesale catalogs, and multi-warehouse inventory each add real scope, not because the connection itself is harder, but because there’s more to map and more to test before you can trust it with live orders.

Best Practices for a Clean Ecommerce Transition

Bring in ecommerce expertise at the assessment stage, not after the ERP work is done. The earlier someone maps out what your connector needs to do, the less rushed the build.

Ask any vendor building your new connector what it actually supports before committing. Our guide to what a Business Central WooCommerce connector needs to include covers the features worth checking for, including two-way sync and per-location inventory.

Run the new connector against a Business Central sandbox for at least a week of real order volume before cutover, not just a handful of manual test transactions.
Time your ecommerce cutover to match your ERP cutover exactly. A gap of even a few days between the two, where one system is live and the other isn’t, is where orders get lost or duplicated.

Once the connector is live, keep the technical side documented. If you’re setting up the connection yourself or working with a new team, our full guide on how the WooCommerce and Business Central integration works covers the API endpoints and field mappings involved.

Keep a rollback plan ready for the first week after cutover. Even a well-tested migration can surface an edge case that only shows up under real order volume, and having a documented way to pause syncing without losing orders gives your team room to fix it calmly instead of under pressure.

Key Takeaways

• A Dynamics NAV to Business Central migration does not automatically carry your WooCommerce integration across. The connector has to be rebuilt.
• NAV connectors break because Business Central uses OAuth 2.0 authentication and a different API structure, not the web service access keys NAV connectors rely on.
• Your Business Central partner handles the ERP. Your ecommerce integration usually needs a separate owner, unless you’ve written it into the project scope directly.
• NAV 2016 support ended in April 2026. NAV 2017 ends January 2027, and NAV 2018, the final version, ends January 2028. None of these dates move.
• Budget and schedule the ecommerce connector rebuild as its own project, running in parallel with the ERP migration, not after it.

Getting Started

Migrating from Dynamics NAV to Business Central is a big enough project without discovering the ecommerce gap three weeks before go-live. The fix is simple to state and easy to skip: name an owner for your WooCommerce integration at the same time you kick off the ERP project, not after.

If you want a second set of eyes on your migration timeline, specifically the ecommerce piece, get in touch and we’ll walk through what your connector rebuild actually needs before your go-live date is locked.

Frequently Asked Questions

Will my WooCommerce connector automatically work after migrating to Business Central? No. Most NAV-built connectors use authentication and API calls that Business Central does not support. A new or rebuilt integration is required, built against Business Central’s REST API and OAuth 2.0 authentication.

Who is responsible for the ecommerce integration during a Business Central migration? Typically nobody by default. Your Business Central implementation partner is scoped to finance and operations, not ecommerce. It needs a separate owner, either your ecommerce agency, a specialist integration provider, or an in-house developer, confirmed early in the project.

How long does Microsoft still support Dynamics NAV? It depends on your version. Extended support for NAV 2016 ended 14 April 2026. NAV 2017 ends 11 January 2027. NAV 2018, the last released version, ends 11 January 2028, according to Microsoft’s official lifecycle listing.

Can I keep using my old ecommerce integration while I plan the migration? Yes, your existing NAV connector keeps working right up until you cut over to Business Central. There is no reason to touch it early. The rebuild just needs to be ready before your ERP go-live date, not before.

Does the ecommerce rebuild delay the overall ERP migration? Not if it’s planned in parallel from the start. It only causes delay when it gets discovered late, after the ERP timeline is already locked and nobody budgeted time for it.

What happens to historical order data during the migration? Historical WooCommerce orders stay in WordPress regardless of what happens on the ERP side. What changes is whether past orders already synced to NAV get carried into Business Central, which depends on whether your migration project includes historical ERP data migration, separate from the ecommerce connector itself.

Do I need custom development, or can a standard connector handle this? It depends on your setup. Standard catalogs with common workflows can often use a configurable connector without custom code. Multi-currency pricing, customer-specific catalogs, or unusual fulfillment logic usually need custom mapping work on top of a base connector.