Migrating to Multitenancy
You can choose to migrate your Dynamics NAV solution to a multitenant deployment architecture where you maintain a single application that is used by two or more companies that store their data in separate databases.
This can make maintenance of your solution easier if you support multiple customers with the same application functionality.
Tenants and Companies
When you upgrade your application and the data to Microsoft Dynamics NAV 2018, you have a database that has the same number of companies as you had before the upgrade. This database is considered a tenant. This does not mean that you have to turn your solution into a multitenant deployment. But it means that you can if you want to.
For example, your Dynamics NAV deployment in the earlier version consisted of a database that has 20 companies. In other words, you support 20 companies that all share the same application functionality. In this example, the companies are separate companies that have nothing to do with each other except that they are supported by you in one database. In Microsoft Dynamics NAV 2018, you can choose to extract the application-wide tables into a separate database and keep the data for all 20 companies in the original database. This becomes a single-tenant business data database. Then, you can choose to split the business data database into one for each company so that you run a truly multitenant environment. The application is stored separately in the application database, and you maintain application functionality centrally. When you modify the application, you make the changes available to one tenant at a time. As a result, if something goes wrong, all other tenants are not affected.
Compare this to earlier versions of Dynamics NAV where a database could contain several companies. These companies could be related or not, but they would all use the same application and write to the same database. Also, when you modified the application, it would affect all companies immediately. So if something went wrong, all companies would be affected.
Note
The email logging functionality in Dynamics NAV requires the Microsoft Dynamics NAV Server service account to have access to the Exchange server. But in a multitenant deployment, this is not always possible.
In multitenant deployments of Dynamics NAV, permission sets are stored centrally in the application database, so only the administrator of the central application can add, remove, or modify permission sets. Instead, the tenants can use user groups to manage permissions. For more information, see Managing User Groups.
Migration Process
If you decide to move to a multitenant architecture, you must complete the following steps:
If your current solution is based on an earlier version of Dynamics NAV, upgrade the database to Microsoft Dynamics NAV 2018. For more information, see Upgrading the Data.
After this step, you have a database that contains the application-wide tables and the same companies as before. But it has been upgraded to the Microsoft Dynamics NAV 2018 database schema.
Move the tables that describe the application to a separate database. For more information, see Separating Application Data from Business Data.
After this step, you have two databases: an application database and a business data database.
Split the business data database into one for each company. For more information, see Creating Tenants from Companies.
After this step, you have an application database and a business data database for each company in the original database. The company-specific business data databases are tenants, and your solution is multitenant.
If you want to move back to storing application tables and business data in a single database, you can use the Dynamics NAV Windows PowerShell cmdlets to merge the databases. For more information, see Merging an Application Database with a Tenant Database.
See Also
Separating Application Data from Business Data
Creating Tenants from Companies
Upgrading the Application Code
Upgrading the Data
Upgrading to Microsoft Dynamics NAV 2017
Merging an Application Database with a Tenant Database