Tenant-To-Tenant Migration architecture model:

Migration comes into play when there are scenarios such as mergers, acquisitions, divestitures, and others where an existing 365 tenant must be moved to a new tenant. There are dedicated personnel and consulting services to help with this migration, so it warrants a brief introduction in a book for multitenant applications.

A specific architecture model called the Tenant-to-Tenant migration architecture model is one of the popular ones among several architectural approaches towards this purpose. This model provides guidance and a starting point for planning with focus on mapping of business scenarios to architecture along with design considerations.

Let us take the traditional names of Contoso for a source tenant and Fabrikam for a target tenant.

A tenant-to-tenant migration can be single-event migration, phased migration, or tenant move or split.

In a single event migration, everything is migrated as a single event. There is a higher risk and a shorter timeline. Single-event migrations larger than 15000 users or 7 TB of site content. In this case, data volumes, network bandwidth, and helpdesk capacity can be limiting factors to scale. The next approach might be preferable when the single-event approach is limiting. Identities migrate to a target tenant and will keep the existing domain as part of the migration. The net benefit to the users is that they keep their email address as say user@contoso.com

Phased migration is the gradual migration of users, services and data. Source domains are not transferred. Users assume a new target domain.  There is lower risk and a longer timeline. The only drawback is the coexistence limitation. Identities will migrate to a new target tenant and will change the brand identity as part of the migration.  Users will have an email address as user@fabrikam.com

Tenant move or split is similar to single-event but it does not include migrating accounts to a new on-premises AD DS forest. This approach should not be used with long-term coexistence for tenant splits. There is additional work required to re-establish existing identities to the new tenant. The identities remain in the source tenant but all the users in the affected domain and all the workloads are moved to a new tenant.

The activities during migration events may vary but include the following:

Before the migration, communication is sent to each user and mailboxes and content are made read-only.

During the  migration, reverse forwarding mail is stopped and new email is allowed to be delivered to the target tenant. Target accounts are enabled, if required. The final data migration is completed.

After the migration, users must recreate their mobile profiles and the client software needs to be reconfigured which includes Outlook and Microsoft 365 clients.

The decision for the choice between the approaches depends on the factors such as if the domains in the target environment must be retained, where the environment to be migrated to is brand new, whether there is continued collaboration between the environments is expected to be in the end-state, whether there are on-premises AD domains that need to be synchronized to Azure, what workloads are being used in the source tenants, how many accounts are involved, is the mail forwarding required after migration, and whether there is a unified Global Address List required.

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