Multitenant Applications and the process of upgrading:

This is a continuation of the articles on multitenancy with the most recent one linked here. This article focuses on upgrading in a multitenant deployment.

Application upgrade and data upgrade are two different things. The data upgrade can be done even after the application has been upgraded. In this case, the old tenants are mounted on the server instance and then the data upgrade is performed.

Data conversion tools are usually provided to assist with the data upgrade process. In this case, the old data with the old version’s table and field structure is converted so that it can work with the new version’s table and field structure.

Before any upgrade occurs, a bunch of prerequisites must be met. Usually, the dry run of an upgrade can indicate potential issues. A tool like the upgrade advisor can assist with this discovery before the actual upgrade is performed. Prerequisites might include converting certain components in the older version, exporting permissions and permission sets from the old deployment, exporting encryption keys from the old deployment, preparing for transitioning, and installing multitenant application components.

The upgrade of the application code is not expected to break any of its functionality. In the multitenant mode, the application code is upgraded first, followed by creating a database on the new platform, then upgrading the application to the database and upgrading the data by mounting the tenant on the application database.

A tenant database can be prepared for data upgrade by first backing it up, followed by uninstalling the software components, and dismounting the tenant from the old server instance. When the data is upgraded on the tenant, it must be mounted on the server instance.

The tenant database might be different from the application database. In such cases, some synchronization is required. Synchronization can occur in the following ways: 1) continuously, which is typical for transactional replication, 2) On demand, which is typical for merge replication. And 3) On a schedule, which is typical for snapshot replication. Replication happens by way of state or operations transfer which is like the well-known log shipping and mirroring options. State gets overwritten on the destinations whereas operations are re-executed on the destination.

Post upgrade tasks include the importing of permission and permission sets, importing encryption keys, and uploading the customer license.

Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN