Migrating from Dynamics NAV to Business Central: What will happen with the integration

By Beate Thomsen, Co-founder & Product Design - August 21, 2026

Want to try Rapidi?

Integrate any CRM and ERP systems fast

TALK TO AN EXPERT

Moving from Dynamics NAV to Business Central does not automatically mean rebuilding your integration — what happens depends on how it was built. Depending on the setup, the integration may need to be rebuilt, reconfigured, or adapted. This blog shares a six-step migration guide to help you move to Business Central without putting your business at risk.

Moving to a new ERP can feel like a major project, especially when your CRM and other systems depend on your existing Dynamics NAV integration. But the move does not necessarily mean starting from scratch.

In our recent webinar, Beate H. Thomsen and Andreea Arseni looked at what happens to your integration when moving from Dynamics NAV to Business Central, what changes between on-premise and cloud, and how to approach the migration in a controlled way.

What this article covers:

 

 

 

What happens to your integration when moving to Business Central?

Moving from Dynamics NAV to Business Central does not automatically mean rebuilding your integration.

What happens depends on how the integration was built and how it connects to Dynamics NAV. There are three possible scenarios: rebuild, reconfigure, or adapt.

Rebuild

If your integration is tied to a specific Dynamics NAV version, reads NAV tables directly, or has field mappings and business rules built into the connector, parts of it may need to be rebuilt.

A useful question to ask is: where are your field mappings and business rules documented?

If the answer is simply "it's in the code," you may be looking at a rebuild.

Reconfigure

If your mapping and business logic are held separately from the ERP, for example in an integration platform, the existing integration may only need to be reconfigured.

This can involve repointing the connection, setting up authentication, and remapping fields that have changed.

In this case, the migration is much closer to a configuration job than a complete rebuild.

Adapt

Some integrations use custom code against NAV web services. In these cases, the connection may carry forward, but code tied to a specific API version or NAV schema may need to be adapted.

This is more than a configuration change, but it does not necessarily mean rebuilding the entire integration.

The important point is that what happens to your integration depends on how it was built, not simply on how old your NAV system is.

NAV to BC Upgrade-1

What changes when moving to Business Central Cloud?

The integration design does not necessarily change, but how you connect to Business Central does.

More can carry over than you might expect. Your integration scope, data flows, matching rules, deduplication, transformation logic, conflict handling, and sync frequency do not automatically change because you are moving to Business Central.

The main differences between Dynamics NAV, Business Central on-premise, and Business Central Cloud are around:

  • Access method
  • Authentication
  • Where the integration engine sits
  • Custom fields
  • Volume and throughput
  • Test environments

For example, moving to Business Central Cloud can mean updating authentication, exposing custom fields through the new environment, and taking throttling and batching into account.

The short version:

Cloud changes how you connect, not what you connect.

How can you keep your migration under control?

Once you understand what needs to happen to your integration, the next challenge is moving to the new system without putting everything on one big cutover weekend.

The webinar's six-step approach is:

1. Map and scope

Decide what moves, what stays behind as history, and agree on the cutoff date.

2. Cleanse at source

Deduplicate and fix your data in the old system before moving it.

3. Dry-run a subset

Test a representative part of the migration and find problems while they are still easier to fix.

4. Run old and new in parallel

Keep both systems live and current with two-way sync. This means no freeze and no lost work.

5. Validate and reconcile

Agree on your acceptance criteria before you start and use them to check the results.

6. Cut over on your terms

Switch off the old system once the new one has been proven, rather than simply because a date was fixed months earlier.

The goal is simple: find the problems during the dry run, not on go-live weekend.

Download the 6-Step Upgrade Guide & webinar resources

Want the full approach with a checklist for each step?

The 6-Step Upgrade Guide covers everything from mapping and cleansing your data to running both systems in parallel, validating the results, and cutting over on your terms.


Download the 6-Step Upgrade Guide Planning your move to a new ERP or CRM? Follow a practical six-step approach to keep your migration under control and avoid a risky big-bang go-live.  

 

Download the webinar slides to get all the insights in one place.

If you're planning a Dynamics NAV to Business Central migration and want to discuss your integration, contact us for an assessment →

Frequently Asked Questions

Will our field mappings still work, or does BC use different table/field names than NAV?

Mostly yes. Business Central inherited Dynamics NAV's table and field names, so most mappings port over unchanged. What you check are the exceptions: fields that were renamed, fields that were obsoleted, and any custom items added to Dynamics NAV that need to be re-exposed on the Business Central side. In practice, it is a reconciliation exercise against a list, not a redesign.

Can we run the integration in parallel during the transition, or does it need to be cut over all at once?

You can, and you should. That is step four. Both systems stay live and current with two-way sync, so there is no freeze and nothing gets lost while people are still working in the old system. A single all-at-once cutover is possible, but it puts all the risk on one weekend and it takes away your ability to fall back.

Does it matter whether BC is on-premise or cloud, in terms of how our existing integration needs to be set up?

It matters, but less than people think, and in very specific ways. The design does not change. What changes is how you connect: cloud is API and OData only with OAuth 2.0, custom fields have to be exposed through an AL extension and an API page, and you have to handle throttling with batching and retry. If your integration already goes through a published interface, that is a configuration job. If it reads the SQL database directly, that is the part that has to change.
About the author

Beate Thomsen, Co-founder & Product Design

Picture of
As Co-Founder of the Rapidi Data Integration platform, Beate has spent over 2 decades on its development, building it around her motto: 'keep it simple, functional yet beautiful.' She holds a Master Degree in IT, Management and Communication and always sees herself as neverending business development entrepreneur with the passion for helping businesses transform, grow and streamline their business operations through Rapidi.
WHY INTEGRATE YOUR SOLUTIONS? There are numerous benefits to systems integration, for example CRM - ERP integration. Enhance collaboration: * Accurate data, 360-degree customer overview and better internal teams collaboration. Increase efficiency: * No double data entries, no switch between systems, no manual errors, automated processes. Boost growth: * Better decision support, increased customer satisfaction, sell more and sell faster.

Related articles

Data Integration Handbook

Your business is 10 steps away from perfectly integrated data systems. Learn about key preparation, best practise and more in our data integration handbook.


FIND OUT MORE
data integration handbook