Every Dynamics NAV to Dynamics 365 Business Central upgrade is budgeted for licenses, partner time, data migration, and training. What goes missing is the line covering every system the ERP was connected to. It tends to surface once the plan is already signed off, as a surprise with a delivery date attached.
Independent survey data supports the pattern. Panorama Consulting Group's , based on data from 170 organizations with a median annual revenue of $200.5 million, reports that more than a quarter exceeded their project budgets. Their most common reason was the unexpected need for additional technology. Panorama also names the degree of software customization as one of the factors that determines how long a project runs. Neither finding is about integrations, but both describe the same failure: work that was not visible during scoping becomes visible once delivery is under way, and it arrives priced at whatever it happens to cost.
Key point: Whether your integration survives a Dynamics NAV to Business Central upgrade depends on how it was architected. The size of the upgrade has very little to do with it. If the mapping and business logic were kept separate from the Dynamics NAV version they point at, the upgrade is a reconfiguration. If they were bound to that version, it is a rebuild. That question can be answered before the budget is fixed.
Will upgrading from Dynamics NAV to Business Central require a full integration rebuild?
Not necessarily, and the deciding factor is usually settled years before the upgrade appears on a roadmap. The ERP upgrade itself is rarely a single clean hop either. Microsoft states that, depending on your current version, to a given release without going through an intermediate release. The table below covers the three setups most Dynamics NAV estates fall into.
| How the integration was built | What the upgrade costs you | Rebuild required? |
|---|---|---|
| Point-to-point connectors wired to one Dynamics NAV version, no reusable mapping layer | Full reconstruction, scoped as a project of its own | Yes |
| Custom code bound to a specific API version or table schema | Engineering time to adapt, on an engineering timeline | Partly |
| Mapping and business logic held separately from the system version | Repoint one endpoint, validate the mapping still behaves | No |
That distinction is structural. It has not much to do with which vendor is better. An integration built for one version of one system is a single-purpose artifact, and changing the version invalidates it. An integration that treats the endpoint as a swappable component keeps its logic when the endpoint moves.
Why this pairing is a better case than most
Something here is specific to Dynamics NAV and Business Central, and it is worth separating from general ERP migration advice.
From an integration platform's perspective, Dynamics NAV from roughly the 2016 releases onward and Business Central share the same underlying connection type. The endpoint changes. What you are connecting to keeps its shape. Where the mapping layer sits above the endpoint rather than inside it, the practical work becomes repointing and validating.
It does not hold in every case. Microsoft draws the same line on its own side: unless those customizations are converted to AL extensions. That same principle applies to the integration layer. Modern Dynamics NAV mappings tend to migrate cleanly. Older estates carrying years of accumulated customization may still need genuine reconfiguration work. Reuse is a real property. It is not an automatic one, and working out which parts of an estate fall into which category belongs in the planning rather than in the cutover.
The migration habit worth breaking
Separate from the integration question, a second assumption shapes how these projects run: treating the data move as a single event.
Most Dynamics NAV to Business Central plans are still built around a cutover. One fixed date, a freeze across the business, and a weekend in which everything has to work first time. It feels decisive. What it actually does is concentrate every risk in the project into the narrowest available window, on a date chosen months earlier by people who could not have known what that week would look like.
A better plan treats the migration as the first run of an ongoing synchronization. Dynamics NAV and Business Central run side by side. A two-way sync keeps both current, so nobody stops working and no delta is lost. Records reconcile against acceptance criteria agreed before anything started. Dynamics NAV is switched off once Business Central has earned it.
A catalog of roughly 65 documented migration failures, gathered from practitioner forums and community threads rather than vendor surveys, shows three patterns repeating. A cutover locked to a date that was not ready. Balances and record counts that did not tie out after go-live. And no agreed-upon definition of "correct going in," which turns the question of whether the migration worked into an argument instead of a check.
Approaches that preserve the integration
Several routes exist for teams that want the connection to survive the upgrade rather than be rebuilt alongside it.
Keep the mapping layer independent. Whichever platform you use, the key question is whether field mapping, business rules, and sync schedules are described separately from the system version they run against. Where they are, changing the version is a configuration change.
Use the migration as the integration. If the two-way sync that runs the parallel period is the same mechanism that will run the ongoing integration afterward, the migration stops being throwaway work. Whatever was built to move the data then becomes what keeps it in step.
Establish acceptance criteria before the extract. Agree record counts, relationships, and financial balances in writing at the start. Go-live then becomes a decision backed by evidence, made calmly, rather than a judgment call made under time pressure.
One option among these is a dedicated integration platform that, by design, keeps mapping separate from endpoints. Rapidi works this way, and Dynamics NAV and Business Central share the same connection type on the platform, which is why a version move becomes a reconfiguration. Other platforms and well-structured custom implementations can achieve the same separation. The property matters more than the product.
Key takeaways
Rapidi ran a session on this subject, working through what actually happens to an integration during a Dynamics NAV to Business Central move. Three things came out of it that are worth repeating here.
First, the deciding factor is not the age or version of the Dynamics NAV system. It is where the field mappings and business rules are written down. That question settles it in about a minute. If the honest answer is that they live in the connector code, it is the rebuild case, regardless of which Dynamics NAV version is involved.
The second point is one most people in the room had not separated out. Moving to the cloud does not change what you connect, but how you connect. Integration scope, data flows, matching and deduplication rules, transformation logic, conflict handling, and sync frequency are not properties of where the ERP runs, so none of them automatically change. What does change is the access method, the authentication, where the integration engine sits, how custom fields are exposed, the throughput ceilings you now share, and the way test environments work. That is real work. It is also a much shorter list than rebuilding the integration.
Third, a note about sequencing rather than technology. Find the problems during a dry run on a representative slice of data, not on go-live weekend. The same defect costs a conversation in the first case and an incident in the second.
A full write-up of the session, including the six-step approach and a longer set of questions on custom fields, C/AL customizations, and cloud connection limits, is available in .
Questions to answer before the budget is fixed
Three questions establish where an existing estate sits. None of them requires a vendor conversation, only a look at what is already in place.
- Is the mapping in our integration held separately from the NAV version it points at, or wired to it?
- Do we have written acceptance criteria for what a correct migration looks like, at the level of record counts, relationships and financial balances?
- Can we run both systems in parallel for a period, or does something in the plan force a hard freeze?
Those answers determine whether the integration line in the budget is a reconfiguration or a rebuild. That difference is usually measured in months, which makes it worth establishing before the plan is signed rather than after.
Frequently Asked Questions
Does upgrading from Dynamics NAV to Business Central always mean rebuilding the integration?
No. That depends on whether the integration's mapping and business logic were kept separate from the Dynamics NAV version they connect to. Where they were, the upgrade is a reconfiguration of one endpoint. Where they were fused to a specific version, a rebuild is likely.
Can Dynamics NAV and Business Central run at the same time during a migration?
Yes. Running both in parallel with a two-way sync is what allows a migration to avoid a hard freeze. Both systems stay current while people keep working, and the old system is switched off once the new one has been validated rather than on a fixed date.
What is the most commonly skipped step in an ERP migration?
Validation and reconciliation against acceptance criteria agreed before the project started. Moving the data is usually the manageable part. Proving it is correct afterward is where the work hides, and it only works if correctness was defined at the outset.
How early should integration be scoped in an upgrade project?
Before the budget is fixed. Whether the integration is a reconfiguration or a rebuild can be determined at the planning stage based on how it was architected, and the difference is large enough that discovering it mid-project leaves no room to absorb it.
Free guide: Six Steps to a Migration You Actually Control
A parallel-run playbook for moving to a new system without a big-bang weekend. The six steps in the order they have to happen, a checklist for each, and what goes wrong at every one, drawn from around sixty five accounts of migrations going wrong posted by the people who lived through them.