NAV to Business Central: What Actually Moves, and What Needs to Change?

In Part 1 I argued that NAV, GP and SL customers should start planning now instead of waiting for a lifecycle date to force the decision.

The next question is always more practical:

"What actually happens when we move from Dynamics NAV to Business Central?"

Most people picture one of two extremes. Either it's a database upgrade, or it's a rebuild from scratch. Neither is right, and the space between them is where most project surprises live.

So let me start with the thing that clears up the most confusion.

It isn't one move. It's an upgrade, then a migration

There is no supported route that takes a NAV database straight into Business Central online. The cloud migration tool moves data from a Business Central on-premises database into an online tenant. NAV isn't a valid source for it.

That means every NAV customer is doing two projects that get discussed as one:

1.      An upgrade, from your NAV version to a Business Central on-premises version the cloud migration tool supports. Usually more than one hop.

2.      A cloud migration, from that on-premises database into Business Central online.

Microsoft's documented routes look like this:

Your current version	Route to Business Central online
NAV 2015 through 2018, and BC 13	BC 14, then BC 25, then cloud migration to online
NAV 2013 / 2013 R2	NAV 2018, then BC 14, then BC 25, then online
NAV 2009 SP1 / 2009 R2	NAV 2013 or 2015, then NAV 2018, then BC 14, then BC 25, then online

There are two mandatory waypoints on that route, and both catch people out.

Version 14 (the 2019 Spring release) is the last version that still understands the old development model, which is exactly why every path passes through it. Worth knowing: its mainstream support ended in October 2023, minor updates stopped, and new customers can't run it in production. It exists purely as a stepping stone.

Version 25 (2024 release wave 2) became mandatory more recently. Starting with 2025 release wave 1 (v26), direct upgrade from version 14 to the latest release stopped being supported, and the path now runs through v25. So you can't go from 14 straight to a current release. If your target is Business Central on-premises rather than online, add one more hop from v25 to the current version on top of that.

The practical consequence: your NAV version doesn't just affect effort, it determines how many technical upgrades you're doing before the migration even begins. A NAV 2018 customer is doing two, to 14 and then 25. A NAV 2009 customer is doing four. That's why "which version are we on" is the first question I ask, and why the answer moves the timeline more than the customization count does.

One caveat on the numbers above. Waypoints shift with release waves, and the v25 requirement itself only appeared with v26. Check the current supported upgrade paths on Microsoft Learn before you build a plan around any specific version.

What "moves" actually means

The cloud migration itself is data replication. You install an Integration Runtime next to your on-premises database, connect it to the online tenant, select companies, and run replication through Azure Data Factory. Initial load, then deltas, then a data upgrade on the online side, then you complete the migration so the online environment becomes the primary system.

Two things follow from that, and the second one catches people out.

Code does not replicate. Tables and fields exist in the cloud only because an extension in that tenant declares them. There is no mechanism that carries application objects across.

And your data is coupled to that code. Data from tables with code customizations can't be carried forward unless those customizations are handled by extensions installed both on-premises and online.

That second point deserves a second read. It isn't only "your C/AL has to be rewritten." Your data in customized tables has nowhere to land until the matching extension exists on both sides of the replication. A custom field on the Item table, or a custom table holding ten years of quality inspection records, stays behind until the AL extension defining it is installed in both environments.

If there's one sentence I'd want a NAV customer to absorb before anyone estimates anything, it's that one.

The real decision: full migration or reimplementation

Microsoft documents two paths, and choosing between them shapes the whole project.

Full migration. All data and customizations. Requires converting C/AL to AL extensions and upgrading through to a current version. This is what people usually mean when they say "migration."

Reimplementation. Essential business data only: master data, balances, a subset of posted historical entries, and setup. It doesn't require converting your extensions, and it doesn't require upgrading beyond version 14. There's a dedicated Business Central 14 reimplementation tool for it.

Both paths still require reaching version 14 first. That part isn't optional.

Both approaches are valid. The right choice depends on the customer's data, customizations, integrations and business requirements, and I've seen both work well.

Full migration tends to fit when:

• Historical transactions are operationally necessary, for example serial and lot traceability, long-running service contracts, or warranty claims against old shipments.
• Customizations are still central to how the business runs, so they need to exist in AL regardless.
• Audit or statutory obligations depend on detailed history being available inside the ERP.
• The third-party solutions in use have Business Central online equivalents.

Reimplementation tends to fit when:

• History is needed for reference and can reasonably live in a reporting or archive system.
• A meaningful share of customizations turn out to be workarounds, unused, or now standard functionality.
• The business wants to standardize processes rather than carry existing ones forward.
• Some customized tables have no clear business owner willing to fund converting them.

If the choice isn't obvious, estimate both. The comparison usually tells you more about the project than either estimate does on its own.

What I'd avoid is treating this as a technical footnote. It's a business decision about what the company actually needs in the new system, and it belongs in the first few conversations, not in a design document six months later.

What usually needs technical work

C/AL customizations

They don't run in Business Central. Not online, and not in modern on-premises versions either, since C/AL was removed from the product entirely. Everything has to become AL extensions, or has to be dropped.

That doesn't mean rewriting line for line. Some of what you customized in 2012 is standard functionality now. Some was a workaround for a limitation that no longer exists. Some nobody uses. I'll cover how I assess this in Part 3.

Reports

Many NAV environments carry years of customized reports. Before converting any of them, I answer two questions: is this report still being opened, and does Business Central already provide an equivalent? Report usage data from your existing system is more reliable here than asking users, who tend to say yes to everything.

Integrations

Integrations deserve their own workstream. NAV environments connect to banking, CRM, payroll, warehouse systems, shipping providers, tax portals and in-house applications. Anything that authenticated against an on-premises service, used a fixed internal endpoint, or relied on file drops on a shared folder needs rework for a cloud tenant.

I've seen a project where the data migration completed cleanly and the numbers reconciled, and users still couldn't work on day one, because an integration nobody had listed as in scope was the thing that actually fed daily transactions into the system.

Third-party solutions

This is the item most likely to set your timeline, and it's the one people discuss last. If an add-on isn't available as an app for Business Central online, you either replace it, rebuild the functionality, or reconsider the path. Check availability early, because the answer can change the whole plan.

Permissions and licensing

NAV permission sets don't carry across cleanly, and licensing works differently. Essentials and Premium are licensed per user, and license type assignment affects what people can do. Teams users with certain Microsoft 365 plans can get read-only access to Business Central data at no extra cost, provided the organization holds at least one Business Central license. This is worth modelling properly rather than discovering during user acceptance testing.

Job queues and scheduled processing

These don't arrive as working configuration. They get set up again, and the behavior differs from what your NAS-based processing did. Inventory them, because they're easy to forget and very visible when they're missing.

Localizations

Country and region specific functionality arrives in Business Central online through localization apps. Verify the localization you need is available for your country, and confirm that any locally customized tax, regulatory or statutory reporting logic has been converted into AL extensions that work with that localization. In my experience this is where India, and other markets with heavy statutory requirements, needs more attention than a generic project plan allows for.

Before you estimate anything

Part 1 listed the questions I'd ask during an assessment, so I won't repeat them here. But this stage adds three that are specific to the route:

1.      Which NAV version exactly, including build? This sets the number of upgrade hops, and each hop is a project with its own testing cycle.

2.      Does every customized table have an owner willing to fund its extension? If not, that data isn't moving, and the business needs to know now.

3.      Which third-party solutions have a Business Central online equivalent? Check before committing to a date.

Answer these and the migration stops being an open-ended question and becomes a scope you can price.

The bottom line

Moving from NAV to Business Central isn't a single event, and it isn't a choice between "everything moves" and "everything gets rebuilt."

It's an upgrade path to version 14 and beyond, followed by a data replication into the cloud, with one hard rule sitting underneath it: your data travels only as far as your code does.

Once a customer understands that, the interesting conversation starts. Not "can we migrate," but "what do we actually want to take with us."

Dynamics NAV, GP and SL: Why I Think Customers Should Start Planning Now

 

If you are still running Dynamics NAV, Dynamics GP, or Dynamics SL, you have probably heard the conversation about moving to Dynamics 365 Business Central.

The question I hear most often is:

"Do we really need to migrate now?"

My answer is usually: you don't necessarily need to migrate tomorrow, but you should start planning now.

I've spent many years working with Dynamics NAV, Business Central, and data migration projects. One thing I've learned is that the actual migration is rarely the hardest part.

The difficult part is deciding what should be migrated in the first place.

Don't Start With the Deadline

When Microsoft announces lifecycle changes, it is natural to look at the dates and start counting backward.

For NAV, Microsoft says the final version was released in 2017 and extended support ends in January 2028. Microsoft also has separate licensing and service-plan changes coming later, including April 30, 2031. These are different milestones, so I would not treat 2028 as a simple "NAV stops working" deadline.

For me, the more important question is not:

"How long can we continue running NAV or GP?"

It is:

"If Business Central is likely to be our next ERP, what should we be doing today to make that move easier?"

That change in thinking can make a big difference.

Your ERP Has Probably Changed a Lot Over the Years

If you've been running NAV or GP for many years, your current system probably doesn't look anything like the original implementation.

There may be:

• Customizations
• Third-party solutions
• Custom reports
• Integrations
• Historical data
• Business-specific processes
• Workarounds
• Old functionality that nobody remembers why they built

Some of those things may still be critical.

Others may no longer be needed.

And this is where I think migration projects become interesting.

Should we really move all of it?

Probably not.

I've seen situations where people start thinking about migration by creating a list of everything in the existing ERP and asking how to reproduce all of it in Business Central.

I think that's backwards.

I'd rather start with:

What does the business actually need going forward?

Migration Is an Opportunity to Clean Things Up

A migration gives you a rare opportunity to look at the ERP environment with fresh eyes.

For every customization, report, integration, and piece of historical data, I would ask:

Do we still need this?

If the answer is yes:

Does it need to work exactly the same way?

And if the answer is still yes:

Is the existing approach the best way to implement it in Business Central?

That last question is particularly important.

Business Central has a different architecture and extension model from older NAV environments. Microsoft documents supported NAV-to-Business-Central migration paths, but the existing application customizations need to be handled appropriately.

So I wouldn't approach the project as:

"Let's convert everything we have."

I'd approach it as:

"Let's understand what we have, decide what matters, and then determine the best way to build it in Business Central."

Data Is Another Big Question

The same thinking applies to data.

One of the first questions in almost every migration discussion is:

"Can we move all of our historical data?"

Technically, that isn't always the most useful question.

I'd ask:

"What data do our users actually need in Business Central?"

Maybe you need all your history.

Maybe you need master data, open transactions, and opening balances, while older history can remain in another system or reporting environment.

Maybe certain historical transactions are needed for operational reasons, while other data is required only for reporting or audit purposes.

There isn't one answer that works for every customer.

Microsoft's current migration tooling supports different data sets depending on the source system and migration scenario. For example, the GP cloud migration process can migrate setup, master data, transactional data, and historical data, while the specific data to migrate is configurable.

That doesn't mean every customer should migrate everything.

It means there are options.

GP Customers Have Migration Tools, But That Doesn't Mean the Project Is Automatic

For Dynamics GP customers, Microsoft provides built-in cloud migration capabilities for supported GP versions, including GP 2015 and later, subject to the documented prerequisites.

That's good news.

But a migration tool doesn't answer questions such as:

• Which customizations should we replace?
• Which third-party products do we still need?
• Which reports should we rebuild?
• Which integrations need to change?
• How much historical data should we keep?
• How do we validate the financial results?

The technology can help move the data.

The decisions still belong to the project team and the business.

What I Would Do If I Were Starting Today

If I were responsible for a NAV or GP environment today and Business Central was the likely destination, I wouldn't start by scheduling the production migration.

I'd start with an assessment.

I'd want to know:

1. What version are we running?

2. How much customization do we have?

3. What third-party applications are involved?

4. What integrations exist?

5. Which reports are actually being used?

6. How much data do we have?

7. Which historical data do users really need?

8. What business processes depend on custom functionality?

9. What can Business Central handle out of the box?

10. What needs to be redesigned?

Once those questions are answered, the migration strategy becomes much clearer.

Don't Wait Until You Have to Migrate

This is probably my biggest takeaway.

Starting early doesn't mean committing to a go-live date immediately.

It gives you time to:

• Understand the existing environment
• Clean up data
• Review customizations
• Evaluate third-party solutions
• Test migration options
• Identify integration changes
• Run mock migrations
• Validate the results
• Train users
• Make better decisions

Microsoft's own migration guidance emphasizes assessment, preparation, test migrations, data replication, validation, and completion as part of the migration process.

That aligns closely with what I've seen in real projects.

The more you understand before the production cutover, the fewer surprises you are likely to have.

My Takeaway

I don't think NAV, GP, or SL customers should look at Microsoft's lifecycle announcements and immediately panic about migration.

But I also don't think waiting until the last possible moment is a good strategy.

If Business Central is likely to be your next ERP, start understanding your current environment now.

Find out what you have.

Find out what you actually use.

Find out what you really need.

Then decide what should move forward.

Because in my experience, a successful ERP migration isn't about moving everything from the old system into the new one.

It's about moving the right things, leaving behind the unnecessary complexity, and taking the opportunity to build something better.

Business Central v25.1 Upgrade Challenge with Master Data Management app

 

Recently, while upgrading version 25.1, we encountered a critical error related to the Master Data Management app by Microsoft. This error halted the upgrade process, presenting the following message:

Error Details:

Could not upgrade the extension '_Exclude_Master_Data_Management' by 'Microsoft' from version '22.0.54157.55195' to '25.1.25873.25900' for tenant 'default' and company 'CRONUS USA, Inc.' due to the following error:

 

'Call to the function 'MODIFY' is not allowed inside the call to 'OnUpgradePerCompany' when it is used as a TryFunction.'

 

AL stack trace: 

  "Master Data Mgt. Upgrade"(CodeUnit 7238).TryModify line 2 - _Exclude_Master_Data_Management by Microsoft

  "Master Data Mgt. Upgrade"(CodeUnit 7238).UpgradeJobQueueEntryFrequencies line 33 - _Exclude_Master_Data_Management by Microsoft

  "Master Data Mgt. Upgrade"(CodeUnit 7238).OnUpgradePerCompany line 2 - _Exclude_Master_Data_Management by Microsoft

  "Upgrade Triggers"(CodeUnit 2000000008).OnUpgradePerCompany(Event) line 2.

Root Cause

The issue was from the Master Data Management app attempting to use the MODIFY function within a TryFunction during the OnUpgradePerCompany process.

A fix has been promised in the upcoming cumulative updates for Business Central. However, until the fix is officially released, users upgrading to version 25 may face this issue.

Temporary Workaround

To bypass the error and proceed with the upgrade, you can temporarily adjust the DisableWriteInsideTryFunctions property in the server instance configuration.

Steps to Apply the Workaround:

Import-Module 'C:\Program Files\Microsoft Dynamics 365 Business Central\250\Service\NavAdminTool.ps1'

Set-NAVServerConfiguration -ServerInstance BC250 -KeyName DisableWriteInsideTryFunctions -KeyValue false

Restart-NAVServerInstance BC250

 

Important Note:

Use this as a temporary solution and revert the DisableWriteInsideTryFunctions property to true once the upgrade is complete.

 

 

Ensuring a Smooth Upgrade to Business Central 25 – SQL Server Full-Text Search Requirement

We encountered this error during a recent Business Central 25 upgrade.

Error: "Text optimized index cannot be created/queried because the SQL Server Full-Text Search component is not installed. Please install the SQL Server Full-Text Search component and try again."

 

This error message, which some may encounter during their upgrade process, indicates that the SQL Server Full-Text Search component must now be installed for Business Central 25.

Upgrading Unmodified C/AL Application to version 25 - Business Central | Microsoft Learn

Here’s how to add the Full-Text Search component to your SQL Server for Business Central 25:

 

Steps to Install SQL Server Full-Text Search Component

1.      Open SQL Server Installation Center.
If your installation media is accessible, launch the SQL Server Installation Center.

2.      Navigate to Installation.
Click on Installation from the sidebar.

3.      Choose “Stand-Alone or Add Features Option.”
Select New SQL Server stand-alone installation or add features to an existing installation

 

 

4.      Add Features to an Existing Instance.

             Click Next through the initial dialogs until you see the Installation Type dialog.                   Here, choose Add features to an existing instance of SQL Server.

5.      Select Full-Text and Semantic Extractions for Search.

             Under Database Engine Services, check Full-Text and Semantic Extractions for              Search to enable the Full-Text Search component.

 

 

 

6.      Complete Installation.

              Follow the remaining prompts to finalize the installation of this feature.

 

  

After installation, you should be able to proceed with the Business Central 25 upgrade without encountering the Full-Text Search error.

 

Resolving the DML Statement Error During the Business Central Upgrade

Upgrading to Business Central can sometimes throw unexpected errors, and one such error we recently encountered involved a DML statement issue with the 'Access Control' table. Here, we’ll walk you through the problem and how we resolved it.

The Error

During an upgrade attempt from BC14 to BC23, the Event log reported the following error related to the 'Access Control' table:

 

The target table 'BC14PROD_UPG.dbo.Access Control’ of the DML statement cannot have any enabled triggers if the statement contains an OUTPUT clause without INTO clause.

Investigation and Findings

Upon investigating the error, we discovered that the 'Access Control' table had several triggers enabled. Triggers in SQL Server are special types of stored procedures that automatically run when specific actions occur in the database.

Resolution

The upgrade process failed because the DML statement included an OUTPUT clause without an INTO clause, which conflicted with the enabled triggers. To resolve this, we deleted the triggers on the 'Access Control' table.

Steps to Resolve the Error

1.    Identify Triggers: First, identify any triggers associated with the 'Access Control' table.

2.      Delete Triggers: Next, delete the identified triggers.

3.      Re-run the Upgrade: After deleting the triggers, we re-ran the upgrade process, which completed successfully.

Conclusion

If you encounter the DML statement error during your BC upgrade, check for and remove any triggers on the associated table. This straightforward solution allowed our upgrade to proceed without further issues.

 

We hope this insight helps others facing similar upgrade challenges. If you have any questions or need further assistance, feel free to reach out in the comments below.

 

Happy upgrading!

Failed to connect to the database. Error message: bad JSON escape sequence: \S.

We recently upgraded one of customers from NAV2016 to BC Cloud.

One of the critical step in this upgrade is to move data from BC OnPrem to BC Cloud using Intelligent Cloud/Cloud Data Migration using “Microsoft Integration Runtime Configuration Manager” tool.

We got below error while testing the Connection to the database in tool.

Failed to connect to the database. Error message: bad JSON escape sequence: \S. Path ‘properties.ConnectionString’, line 5, Position 78

Solution: Make sure to use 2 back slashes in your SQL Server details.

We used 1 back slash in above image as CD-NavToBC\SQL2016

But it should be CD-NavToBC\\SQL2016

End of Mainstream support for Microsoft Dynamics NAV 2015

January 14, 2020 marks the end of mainstream support for Microsoft dynamics NAV 2015. We will not get any new regulatory features or hotfixes for this version anymore.

Please note the date, April 13, 2021 will be end of mainstream support for Dynamics NAV 2016.

Please migrate your NAV versions to D365 Business Central.

Please contact me if you have any questions on migration and/or training required on D365 BC at pmohanakishna@hotmail.com

How to keep custom extensions in Cloud tenants while upgrading

I hope some of you must have noticed custom apps are uninstalled while upgrading Online tenants.

How can we keep them while upgrading?

As per Microsoft, If we upload extensions via extension management page then those apps won't be uninstalled while upgrading.

If we install extensions via Visual studio code then those apps will be uninstalled while upgrading.

So always keep it in mind to install/upload apps via extension management page and not via visual studio code.

Upgrade Steps from NAV 2017 CU4 to NAV 2018 CU2

Upgraded one of our customers from NAV2017 CU4 to NAV2018 CU2.

Steps are:

1.     Take backup of your NAV2017 CU4 database from SQL

2.     Upload Partner License and restart service

3.     Open Extension management page in NAV2017

Uninstall standard extensions

4.     Run this command to unpublish from powershell (example)

Unpublish-NAVApp -Name "Sales and Inventory Forecast" -ServerInstance dynamicsnav110

5.     Delete records of Debugger breakpoint table from database using SSMS

6.     Stop NAV2017 CU4 service

7.     Open current NAV 2017 CU4 database in NAV 2018 CU2 environment and do the convert.

8.     Delete all objects except Tables.

NOTE: I have created all fob of NAV2018 with customizations before.

I have manually merged customizations as there are only less than 20 objects modified.

You can use power shell merge commands if there are lot of customized objects.

9.     Import all objects fob file with Replace all option from Import Work Sheet. (With Later Option in Synchronize Schema)

10.Import Upgrade toolkit fob (With Later Option in Synchronize Schema)

11.Start NAV 2018 CU2 service

12.Sync-NAVTenant in Powershell

13.Compile all objects with Validation

14.Run data upgrade from Tools->Data UpgradeàStart (you can do it from Power shell also)

15.Following objects, you have to delete from converted database.

Type	ID	Name
1	9192	Pending Company Rename
3	83	Change Global Dimensions
8	1605	Office No Company Dlg
8	1802	Assisted Setup Part
8	2502	Extension Marketplace
8	5073	Sales Cycle Stages List
8	9627	Data Source List Part
8	9626	New Page Patterns List Part

16.Delete Upgrade related objects. (Version List UPG*)

Only Publish below app, don’t install

17.Publish extensions from NAV2018CU2 DVD and install if required

Publish-NAVApp -Path "C:\Install\Dynamics NAV\NAV2018CU2\Extensions\SalesAndInventoryForecast\SalesAndInventoryForecast.navx" -ServerInstance dynamicsnav110

18.Upload Customer license and restart service