• Home
  • /Blog
  • /Why and how to upgrade from Dynamics NAV to D365 BC?


Why and how to upgrade from Dynamics NAV to D365 BC?

Why and how to upgrade from Dynamics NAV to D365 BC?

Upgrading from Dynamics NAV to D365 BC requires more than simply migrating your data from Dynamics NAV and flipping the switch in D365 BC. While it is not as time-consuming and complicated as other Dynamics NAV upgrades, it still needs strategic planning and preparation before you commence with it.

Why upgrade from Dynamics NAV to D365 BC

  • Cost-effective – It won’t be true if one says that D365 BC is less expensive than Dynamics NAV on-premise. However, once installed, D365 BC enables you to track monthly expenditure and plan your budget more effectively which overall makes it less expensive than NAV. Moving to the cloud eliminates the need of spending on infrastructure, costly servers, and upgrades to licensing fees. To put it bluntly, transitioning from NAV to BC is the final upgrade you will ever have to pay for. Once implemented, updates happen automatically and are free of cost on D365 BC.  
  • Power BI, AI, and machine learning analytics – Manual errors and inefficiency can be battled out with the help of machine learning and artificial intelligence in D365 BC. It helps you monitor equipment, create target ads, filter spam, analyse, and forecast. You are able to make better decisions based on accurate insights acquired from Microsoft’s Power Platform, made up of Power BI, Flow, and Power Apps.  
  • Enhanced security – Data is the new oil. Almost every company out there is investing money and time in securing its data. Microsoft D365 BC Cloud has one of the most secure systems. It is an industry leader when it comes to detecting, protecting, and responding to cyber threats. With such excellent security, you do not have to worry about data theft and focus on achieving your business goals.  
  • Feature-rich – When compared to NAV, D365 BC comprises way more new features such as fuzzy search, late payment prediction, focus mode, and the list is long. The functionality of D365 BC is being expanded and strengthened every day by the addition of new apps and add-ons to AppSource. 
  • Advanced software – D365 BC flaunts an intuitive look and feel that reduces training and ramp-up time for users. Furthermore, the flexibility offered by D365 BC is commendable because it can be accessed from anywhere, at any given time. 

Considerations before the upgrade:

D365 BC is built on the exact same code base as Dynamics NAV, ensuring accurate consistency between the on-premise and cloud versions of D365 BC. This means that it is fairly easy to migrate from Dynamics NAV to D365 BC.

It is only possible to upgrade to D365 BC online from supported versions of Dynamics NAV on-premise, but a hassle-free upgrade requires that the application’s customizations are made as Extensions. In other words, data from tables with code customizations cannot be transferred directly to D365 BC. It is therefore important to be aware of any corrections before embarking on an upgrade project.

  • An end to V1 Extensions – With D365 BC, V1 Extensions are no longer supported and must be converted to the V2 Extensions before upgrading.
  • Upgrade codeunits – When you make changes to the database schema, D365 BC automatically monitors whether these changes are damaging to the functionality of the application or not. If the database monitoring indicates that the change may result in data deletion, the monitor will consider it as destructive and you will be prompted to handle the situation by using upgrade codeunits.
  • Names of variables – With D365 BC, new methods and statements have been introduced. If your current Dynamics NAV solution includes variables where the name is now used by a standard AL method or statement, you will need to change the variables before upgrading to Dynamics 365 D365 BC. Alternatively, you can close the variable names in quotes. If you do not do this and import an object that has this code in text format, it will not be possible to compile the object.
  • Codeunit 1 has been replaced – Codeunit 1 ApplicationManagement, belonging to Dynamics NAV, has been replaced with System codeunits. The change hasn’t removed functionality, but the new System codeunits aren’t customizable. The change will not only affect the upgrade process but also have an impact on how you develop going forward.
  • Deprecated or redesigned functionality – Occasionally, Microsoft will rewrite the existing program code to make it simpler and easier to read while retaining the functionality of the code. This means, for example, that some fields will no longer be used or that the functionality will be moved from the base application to an extension. The upgrade tool will typically handle the impact it may have, but you can find a list of fields that have been phased out in the current version of D365 BC or marked as outdated in an upcoming version.
  • Phased out or redesigned functionality – If you upgrade a Dynamics NAV solution that depends on functionality that has been phased out or changed in the new standard version of D365 BC, you should ensure that the upgrade code units migrate the solution’s data correctly.
  • MenuSuite not used – Unlike Dynamics NAV, where pages and reports were only searchable in the web client if they were included in MenuSuite, pages and reports in D365 BC can, with the help of MenuSuite, instead be made searchable by setting properties on the page and report objects themselves. As a result, pages and reports which previously were searchable in the client will no longer be searchable after an upgrade from Dynamics NAV to D365 BC unless you specify the required object properties.

How to upgrade from Dynamics NAV to D365 BC?

The upgrade process depends on different factors, such as the version of Dynamics NAV that you are upgrading from, and the degree to which your solution differs from the standard version of Dynamics NAV. 

The upgrading process generally involves two major tasks:

  • Upgrade the Application Code
  • Upgrade the Data 

Upgrade the application code:

Typically, customers want all the customizations that have been implemented in their existing databases to be migrated to their new Business Central databases. Depending on the version of Business Central that a database is being upgraded from, the amount of code changes between the two versions can vary. To upgrade the application code, you must merge code from different versions of the application. This merge process is known as a code upgrade or application upgrade. You must upgrade the application before you upgrade the data.

Single-tenant and multi-tenant deployments

The process for upgrading the application code is basically the same for a single-tenant and multi-tenant deployment. However, there are some inherent differences because with a single-tenant deployment, the application and business data is included in the same database, while with a multi-tenant deployment application code is in a separate database than the business data (tenants). Here is the general process for each deployment type. In the tasks that follow this section, tasks are marked as Single-tenant only or Multi-tenant only where applicable.


  • Upgrade the application code.
  • Create a new database on the new platform.
  • Import the upgraded application to the new database.
  • Export the application to a .fob file.
  • Upgrade the data. Here you will import the .fob file.


  • Upgrade the application code.
  • Create a new database on the new platform.
  • Import the upgraded application to the new database.
  • Upgrade the data by mounting the tenant on the application database.

How to upgrade the application code?

  • Install the Prerequisites and Tools
  • Prepare the Application Object Text Files
  • Merge Versions
  • Handle Conflicts
  • Import and Compile Merged Objects in an Empty Database
  • Check/change the application family and version
  • Build object search index

Upgrade the data:

How to upgrade the data?

  • Create full SQL backup of old database
  • Uninstall all extensions in old database
  • Upload Business Central partner license to old database
  • Delete all objects except tables in old database
  • Clear server instance and debugger breakpoint records in old database
  • Convert old database to Business Central
  • Import upgraded application objects to converted database
  • Connect a Business Central Server instance to converted database
  • Compile all objects in converted database
  • Run the schema synchronization on converted database
  • Run data upgrade on converted database
  • Upgrade Javascript-based control add-ins to new versions
  • Publish and generate symbols for extensions
  • Upgrade or repair V2 extensions
  • Publish and install local functionality extensions
  • Import permission sets and permissions
  • Set the language of customer database