Introduction
A common scenario in the Cloud industry is the consolidation of workloads. Consolidation means to combine resources and workloads from different locations or management units (e.g. Cloud tenants) into a single one for centralized management and cost efficiency. One such scenario in Microsoft Azure is the migration of the resources of a Microsoft 365 tenant into another Microsoft 365 tenant.
Why perform a Microsoft 365 tenant to tenant migration?
One common reason for performing tenant to tenant migrations in Microsoft 365 is related to companies physically relocating from one country to another and therefore need to change the country field in their Microsoft 365 tenant. This is also know as change of data residency, i.e. change of Microsoft 365 data center location, which occurs automatically depending on the choice of the target physical country. The change of the country field and data residency is not feasible after the tenant has been created. Another common reason is the consolidation of Microsoft 365 subscriptions for cost efficiency and for simplifying invoicing and other financial procedures. Other common reasons which justify a tenant to tenant migration are the change of a company’s brand name, legal regulation and data privacy requirements (again related to data residency). Last but not least, mergers and acquisitions (or exactly the opposite, i.e. creation of multiple independent sub-divisions under a business group) are also the driving factors for considering a tenant to tenant migration.
Before commencing with a Microsoft 365 tenant to tenant migration project, proper sizing and design should be carried out. This article includes the most important design considerations to be made in tenant to tenant migrations.
Third party tenant to tenant migration tools
It may be an option to carry a tenant to tenant migration manually, by crafting a manual transition plan. However this can be really complex and very error prone, depending also on the size of the source and target environments. Therefore a manual approach to this type of migration should be avoided. The other alternative is to dedicate a specialized engineering team to carry out the migration by creating, testing and executing a series of Powershell scripts or an in-house developed tenant to tenant migration tool which will be utilizing the Microsoft 365 APIs. Again, creating a custom Powershell-based scripting library or application software tool for the migration can be a challenging, complex and time consuming task. The business, project management and end-user communication aspects of such a migration project should not be underestimated either.
As a result of the above project planning considerations, choosing a trusted third party tenant to tenant migration automation tool should be preferred in most cases. This may increase the budget but will significantly reduce the possibilities of errors during the migration. A third party migration tool almost certainly takes into account all the tricky parts of a tenant to tenant migration and handles them properly. Usually each tenant to tenant migration tool software vendor provides documentation and training for their product, as well as technical support before, during and after the migration.
The following list is not a conclusive list but it is a summary of the most well-known tenant to tenant migration tool vendors available today, provided in alphabetical order:
- Avepoint
- Binary Tree
- BitTitan
- CodeTwo
- ProvenTeq
- Quadrotech
- Quest
- Sharegate
- Slimflofy
- Skykick
- Skysync
- Tervela
- Transend
- Xillio
Sources
https://docs.microsoft.com/en-us/exchange/mailbox-migration/migrate-mailboxes-across-tenants
https://docs.microsoft.com/en-us/power-platform/admin/move-environment-tenant
