Tenant-to-tenant migrations in Office 365 are generally prompted by overarching changes to a company’s structure as would be driven by growth indicators such as business acquisitions and mergers.
Executing this sort of migration requires some significant assessment of the tenants involved, a planning phase, and finally, there are a series of steps involved in carrying out the migration itself. Today, we’ll look at some industry-standard best practices for preparing for such a migration, and then we’ll dig into the steps you’ll need to follow to migrate your M365 tenant.
There are essentially three scenarios in which you will have to perform an O365 tenant migration – when one company that uses M365 buys another that also uses it; when a company that uses M365 buys a company that doesn’t yet use it; and when a company that doesn’t use M365 buys another that does use it.
Whichever of these scenarios you’re facing, there are some fundamental assessments that you should undertake before moving forward with a migration.
Workload Adoption: You’ll want to evaluate the detailed usage level of key applications such as Exchange, OneDrive, Microsoft Teams/Skype, and SharePoint. You’ll also need to take stock of your available licenses – both those in inventory and those that have already been assigned to users.
Protocols: Next, you’ll need to identify which specific protocols are being used within the system. A third-party tool can be very useful at this stage. For example, CoreView shows which protocol is used to access mail (MAPI, POP3, IMAP) within Exchange, and it can infer what other types of access methods are currently being used to access other M365 applications, such as Microsoft Teams.
Devices: Lastly, as part of the assessment, IT teams should look carefully at the degree of security for end-user devices that have access to the tenant, as well as how the target company manages their Microsoft Office 365 environment, including if they have Virtual Tenants, RBAC, and O365-specific security policies.
With these assessments in hand, you’ll be ready to move on to preparing your domain for the migration event.
You’ll first need to verify that there is adequate space in the migration-target tenant for the data from the incoming tenant. You may also need to allocate additional licenses as well.
Next, you’ll need to ensure that accessible administrator accounts exist in both tenants. Additionally, if you are using a third-party migration tool, you will likely need to create one or more admin accounts there as well.
Then, you’ll need to create user mailboxes, resource mailboxes, and distribution groups within the target tenant that align with the parallel resources that exist in the tenant being migrated. And finally,
you will likely need to integrate Active Directory Domain Services (AD DS) with a tool such as AD DS tools as well.
Next, you’ll need to verify the target domain in M365. To do so, you’ll need to enter the target domain, configure DNS TXT records, and connect a source domain to the targeted M365 admin center.
You’ll want to ensure that the domain is only being used by a single tenant. If there is more than one tenant associated with a given domain, verification will fail.
After having completed the above steps, you’ll see the verification results within 72 hours.
After having verified your domain, you’ll need to create a list of user mailboxes that you can store as a CSV for eventual ingest into your target tenant. As you do so, you’ll want to note the lowest value of Time To Live (TTL) on the Mail Exchanger (MX) record of the primary email domain. This will make it easier to stop inbound emails from coming into the source tenant, thus complicating the migration.
Next, you’ll need to disable the directory sync for the source tenant so that it doesn’t sync with the targeted tenant accidentally during the migration process.
Then, you can stop incoming emails by updating the primary MX record to an unreachable value – i.e., a value that is less than the lowest TTL value you noted earlier.
After that, you’ll need to confirm that all objects from the primary mail domain in the source tenant have been deleted before you move one Office 365 mailbox to another account.
And finally, you’ll need to prepare the target domain by verifying the source tenant in the target domain (similarly to what was described for the target tenant above). You’ll also need to activate new users in the target domain and assign licenses as needed.
NOTE: The primary email address for users being migrated must align with the source domain for a successful migration.
Tenant-to-tenant migrations can be carried out using PowerShell scripts, but this method is extremely complex, and would likely involve a significant investment of time and IT resources – even for an Exchange expert. As such, IT teams generally look to third-party migration tools – such as CoreView offers – to streamline the transition via automated workflows.
Regardless of the tools you choose to use, you will ultimately need to carry out each of the following steps in turn. However, you may adjust your migration plan depending on the number of employees whose data is being transferred. If you have fewer than 500 accounts to migrate, you will likely be able to achieve this in a single pass, but if you have more than that, you’ll likely want to batch the migration jobs.
In order to transfer the M365 subscription to the target tenant, you’ll first need to purchase the plan to which you wish to transfer data.
Next, you’ll need to remove any custom domain from the source tenant and set up the custom domain in the target tenant.
Finally, you’ll want to be sure to cancel any subscription to the source tenant’s services.
In order to transfer M365 mailboxes, you’ll need to transfer the Outlook profile along with any third-party licenses that apply. Any new users or groups must be synced with the target tenant.
The domain must get added to the target tenant.
You’ll then need to create the CSV of mailboxes to migrate we described above, and you’ll need to also stop inbound mail with the application of the TTL rule described in the Scheduling Your Migration section above. Finally, you’ll need to verify the source tenant and new mailboxes in the target tenant.
M365 OneDrive migrations are generally the most complex and technically demanding phase of a larger migration. CoreView can help simplify this process considerably.
Regardless of the method you choose, you’ll first need to create a source connector and configure it. Then, you’ll need to create a target connector and configure it as well.
Mergers and acquisitions are part of the enterprise landscape. When they happen, IT teams need to undertake a massive effort to combine the M365 records of two companies, which involves a significant number of highly complex steps. Moreover, IT teams need to assess the readiness of both tenants involved before combining them, to avoid accidentally introducing serious security flaws into your M365 system.
CoreView dramatically reduces the complexity of these tasks by providing access to every step described above from a single user interface. Additionally, CoreView provides sophisticated monitoring and alerting for all aspects of your M365 deployment, so that you can more easily confirm the security-focused readiness of both tenants, and you can continue to monitor the consolidated tenant after the migration is complete to ensure that you’re well secured and in compliance.
