Tenant-To-Tenant Migration architecture model (continued):

This is a continuation of the previous article on Migration architecture models. Specifically, it focuses on Microsoft365 migration, tools, and migration of on-premises tenants.

The Tenant-to-Tenant migration architecture model is one of the popular ones among several architectural approaches towards tenant management. A tenant-to-tenant migration can be single-event migration, phased migration, or tenant move or split. These are also referred to as batched migration or cutover migration.

In a single event migration, everything is migrated as a single event. There is a higher risk and a shorter timeline. When there is no strict organization and users wear multiple hats or belong to multiple project teams, it becomes hard to segregate them into migration groups.  A single event can be used to migrate all and eliminate the need for coexistence considerations. The net benefit to the users is that they keep their original email address. The drawback is that automation might rely on APIs and there might be rate limits on their invocations.

Phased migration is the gradual migration of users, services, and data. With separation into multiple migration groups, there is continuity of access for users to their emails and meetings. There is lower risk and a longer timeline. The only drawback is the coexistence limitation.  Users will have an email address in a new domain and a tool might be required to do the migration.  A variety of third-party tools are available from say Consulting Services to migrate Exchange mailboxes, public folders, SharePoint sites, OneDrive folders, Office 365 groups, while users can help themselves with native capabilities from Intune and Windows 10 such as for subscription activation license. Native tools also have their place but they make calculation for Total Cost of Ownership a bit tedious.

Since the migration tasks are complex, there may be many activities occurring simultaneously such as migration of servers and other infrastructures. Coordination to minimize effort and risk and to avoid overlap is essential. Migration might not even be scheduled in certain periods. The overall picture matters more for phased migrations. This warrants the use of an overall plan where individual projects such as Exchange, SharePoint and Teams workload migrations can be managed.

Talking to users is critical towards this purpose. Certain business functions might not even be on the plan until that occurs. Even though these might be limited in number, they matter to the overall migration.

Advanced reporting tools for large and complex projects or periodic migrations can reduce stress because they anticipate common needs and have lower maintenance than custom or ad hoc reporting. Reports also help backwards in the planning process.

As with all projects of this nature, some discretion is required between balancing migration with one or the other factors. Sometimes, a single tool helps better than having teams onboard on multiple native tools.

Migration tools like BitTitan MigrationWiz for migrating Microsoft 365, Exchange and G Suite as well as Fast Cloud File migrations for SharePoint Data are also well-known. Mover.IO is a free migration manager from Microsoft for work or school. These tools work very well for hybrid environment and tenants. When doing the migration directly, it might be better to 1) recreate the teams’ structure by adding users and permissions at the target tenant, 2) migrate content from the associated SharePoint Sites and upload to the target tenant, and 3. Export data from the Exchange mailboxes and import it into the destination. A back-of-the-envelope calculation of the time and cost would be helpful to this case.