Switching modes:

This is a continuation of the articles on multitenancy with the most recent one linked https://1drv.ms/w/s!Ashlm-Nw-wnWhLZlxLBXSWQZmcirVA?e=ugcdca . This article focuses on migrating between deployment modes. 

It’s possible to convert a solution from a multitenant deployment mode to single-tenancy. This article describes some of the steps.

Data and applications are partitioned and isolated from one tenant to another in a multitenant application. The application data is in a dedicated application database, separate from the business data in the tenant database. The revert to a single-tenant deployment mode requires the revert of the separation of application data and business data and the merging of the two databases. A single-tenant can be folded from the multitenant mode and leaving the remaining tenants in the existing deployment deployment by adding the application tables to the relevant tenant database and leaving the original application database unchanged. If the application data is separated into a dedicated database, but it is not used in a multitenant deployment mode, the databases can still be merged.

Application code instances and configurations per tenant are still easily honored because as the applications instances are decreased the multitenant mode ensured that the infrastructure was shared. This made it easier to scale in or out and continues to work for migrating back into the single tenant mode.

Data, on the other hand, requires immense protection, isolation and compliance standards. It is not easy for the shared infrastructure to interpret the data belonging to a tenant. The multitenant solution provider can move or migrate the data one by one but it cannot make changes to syntax, semantics or format.

Even when the data is allowed to be read for operational purposes, the size of the data can vary from a few GB to TeraBytes. In such cases, even a migration of data from one table to another poses a long running operation that must be carefully planned and executed. It’s best to move a single record at a time in an idempotent manner and with failure detection and corrections so that when the operation succeeds for one single record, it can be repeated for all the records in the table.

When we refer to a tenant, we refer to it by the tenant ID but it is also possible to refer to them by the hostnames for the tenants in the deployment. A tenant specific sub-domain is setup in this case. The tenant host name, mytenant.myservice.com must be specified as an alternative in the tenant configuration.  The URL can specify the tenant ID and the tenant host name if we specify the hostnames as an alternative IDs for tenants.