Microsoft 365 tenant-to-tenant migrations happen very often. There are merger and acquisitions, such as when a company buys another company. And there are divestitures, such as when a company gets partially outsourced to another company. This three-part blog series covers everything you should be aware of when you, as an admin, get involved in tenant to tenant migrations.
Part 1 covers the discovery of identities, workloads, data, and security.
Part 2 covers the migration itself, like which workloads can be moved, what needs to be done to prepare for migration, which data can be migrated and if there are any 'gotchas' to expect, and public available PowerShell scripts that makes your life a little bit easier.
Part 3 covers post-migration tasks that need to be done, measurement and reporting, what defines success or failure, and what things could be automated for the next tenant to tenant migration.
Identities – whether federated, managed or cloud-only – are the most important parts for storing data in the Microsoft 365 ecosystem. Every object like users, groups, Teams, etc., will be associated with an identity. Identity inventory, mapping, and synchronization can be fantastically complicated.
Identities are not migrated per se because they are associated with the service itself. For example, a mailbox can be mapped to an identity, and a Team is mapped to Group. Therefore, identities are basically synchronized between tenants and not migrated. Everything you move between tenants will be associated with an identity.
What kind of identity and permission remapping does the business require? And how do you analyze and identify all required objects that should be migrated? There are a couple of things to consider first:
- Can your identity management tools support the synchronization process?Tenant to Tenant migrations require a lot of planning and communication. Depending on the fact that Microsoft offers only some native migration capabilities within the Microsoft 365 ecosystem (as of Feb. 2021), third-party vendors can help you with how to plan, organize, communicate, and migrate your data between Microsoft 365 tenants. The following checklist can help you analyze and map your identities for all different MAD (Merger & Acquisitions, Divestitures) scenarios.
For merger and acquisitions, companies often migrate from one or multiple tenants to a single tenant. According to the imaa study, more than 790,000 transactions have been announced with a known value of over $57 trillion USD. Important components that you should consider during a merger & acquisition scenario are the following:
- Communication between business units. Communication is key. A structured project plan with all necessary stakeholders is essential. Recurring meetings about the status, identified migration objects, and possible issues are highly recommended.
The more identities that need to be mapped, the more complex it is. Separate Excel spreadsheets are very useful to map and verify the identity synchronization between multiple source and target environments.
Partial or full disposals of business units are even more complicated when it comes to identity synchronization. The key points in such a project are the same as for merger and acquisitions, but with an additional focus on the identity of the data itself.
Figure 2: What can be migrated and what cannot?
But what does this mean in a real business scenario? Consider your organization uses Microsoft Teams, SharePoint, and Microsoft 365 Groups. People from many different business units are members of these identity objects and you are asking yourself:
- Do we need these Teams and Groups in the target environment as well?
- Are the members of the disposal business unit just participating or are there important data stored?
- Do these objects have an email address mapped for external customer communication and can we use the same email address and domain in the target environment as well?
The technical part is much less complex than the organizational part when it comes to identity synchronization. Custom PowerShell scripts or third-party party migration tools can help you with how to identify and map the right objects together.
Depending on your Microsoft 365 subscription, there are a lot of workloads which hold your organizational and personal data. Besides Microsoft 365, there is also the Microsoft Azure part where you might have SaaS and IaaS workloads deployed.
Let’s start with the Microsoft 365 workloads that need to be discovered for migration. A good entry point is to analyze your Microsoft 365 subscriptions and licenses. Whether you are responsible for managing a small, medium, or large organization, everyone has to deal with the license jungle.
ENow can help you to monitor your license assignments with their Office 365 License Management Solution.
For example, there might be duplicate license assignments, your users aren’t using certain features from the assigned license and you probably could assign a smaller one and save money. Furthermore, there might be some users who are on paternity and maternity leave, or sabbatical leave and maybe just need to preserve the Exchange Online mailbox data which doesn’t requires a license (Inactive Mailboxes feature).
Another great third-party source is Matt Wade’s Office 365 periodic table to get an overview of all workloads that are available. And the best thing is you can create your own Office 365 periodic table based on your subscriptions and licenses.
By clicking on a workload, you will also get more information like descriptions, functionality, and much more. Of course, you can use PowerShell and Graph API to get subscription and license details as well, which is covered in Part 2 of this three-part blog post series.
Now you should write down and record all workloads that needs to be migrated. In the next step we will have a look at the stored data itself and how you can get reports about the number of files and storage that is being used.
Data for specific workloads is stored in different places. Some of the most common workloads used every day are:
- Exchange Online: internal and external communications happen mostly via email. So it's likely every Microsoft 365 user has a mailbox associated where data is stored. Exchange Online uses its own storage system, called ESE (Extensible Storage System).
- Microsoft Teams: internal communication within a group of people or a project team happens mostly in Teams. You can leverage 1-to-1 chats which as stored in the Exchange Online mailbox of the specific user itself, group chats which are stored in the underlying Microsoft 365 group mailbox, channel messages within a specific Team, files stored in SharePoint Online, and meeting recordings saved in OneDrive for Business. You also might have additional built-in or custom tabs bound to a Team.
- SharePoint Online: file collaboration and sharing (even with external customers and partners) is key for business. Besides the storage of files itself, SharePoint Online can be used for many other things like corporate intranet, knowledge database, etc. The data will be stored in SQL databased in the background. Even Yammer groups SharePoint to store files and documents.
- OneDrive for Business: stores corporate data on a personal basis. Like SharePoint Online, OneDrive for Business stores data in a SQL database and can be shared internally and externally.
Of course – as you can see in the Office 365 periodic table – there are a lot more workloads that store data. Depending on your organization, subscriptions, and business, there may be other workloads that you need to focus on. Some of the data can easily be exported by the user itself (e. g. OneDrive for Business), some data can’t (Microsoft 365 Groups) and even then, there might not be an API available as of writing this post to programmatically export and import the data (e. g. Microsoft Forms).
Therefore, it’s important to create your own unique Microsoft 365 table of all your workloads and data and decide with the business, what data needs to be migrated and sort it by priority. Also add an exception column to it and define which data within a workload you could do without. An example of such a table could look like this:
Workload |
Data |
Priority |
Exceptions |
| Exchange Online | User mailbox data | 1 | Inbox rules, Outlook categories |
| Microsoft Teams | Teams itself | 1 | Naming convention can be different |
| Channel messages | 2 | Timestamp can be UTC | |
| 1-to-1 chat messages | 3 | Can be archived in a PST file as well | |
| OneDrive for Business | Files and folders | 1 | Online/offline decisions per user |
| Sharing links | 2 | Internal required/external not required |
Table 1: Data Priority Table
You might wonder why you should create a table and prioritize the individual workload and data: it’s simply not possible to migrate everything from one Microsoft 365 tenant to another. Depending if you are using native migration capabilities or choose one of the third-party vendors available out there – you always have to compromise. Part 2 of this blog post series will go into detail as to what data can be synchronized, migrated, exported, and imported, what tool can be used or if there is a possibility to do some PowerShell and Graph API stuff on your own or from the community.
Very similar to Microsoft 365, there are Azure workloads that might be used by your organization as well. A great third-party source is David Summers’ Azure periodic table to get an overview of all workloads that are available.
Figure 4: The Periodic Table of Azure (image credit: David Summers)
By clicking on a workload, you will also get more information like descriptions, functionality, and more. Of course, you can use PowerShell and Graph API to get workload details as well. Now you should write down and record all workloads that need to be migrated like you did for Microsoft 365 workloads as well. This allows you to get an overview and talk to people within your organization if these workloads must be migrated and how they could be migrated if necessary.
The used data in Azure can be huge and I can’t write down any possible workload that could store data. Therefore, it’s crucial to write down all used services that need to be migrated or re-created in the target after the Tenant to Tenant migration again. Some examples of my personal experience in the last couple of projects:
- Enterprise applications: Pretty sure there are some Enterprise applications added to your source tenant. This could be a custom app to access Exchange Online mailboxes with Graph API, or simply someone – if allowed by your organizations security policy – added an app that allows Amazon’s Alexa to read out your schedules for the day during your daily dose of coffee. Some applications might be mapped to certain users, some apps might be critical to your organization and need to be verified.
- Application authentication: Your organization might use Azure AD Application Proxy to leverage conditional access policies for your on-premises legacy authentication apps. Or your organization may use Azure auth for third-party apps instead of AD FS or another third-party IdP.
- Azure Automation: Depending on the level of automation, you might need to check Azure managed identities, the usage of Azure key vault, certificates for certificate-based authentication (Graph API / EXOv2), and of course your individual automation scripts that might need to be exported.
- IaaS and SaaS: Whether your organization uses virtual machines, server-less computing components or just web services for hosting your corporate website, keep in mind that these things might need to be migrated as well.
Of course, not all workloads and data in your Azure subscriptions need to be migrated. If your organization allows you to use more than one Azure subscription outside of the “main Microsoft 365 tenant”, then you can keep some things running in your current Microsoft 365 tenant as well. This needs to be clarified with the business and all use cases should be identified with a pro and con list.
Security and governance play an important role, especially since many people are working from home. But these parts can become crucial for your organization's tenant migration project. Hopefully, your organization has currently set up a second factor for authentication and policies to protect mobile devices from unauthorized access. Also, document and file encryption and labeling help to protect sensitive information within and outside your organization.
There might be completely different policies in the new target tenant than you have in your source tenant. A little pain for your end users is also that they must re-configure any used authenticator app on their mobile devices again, even if your User Principal Name and primary smtp address stay the same after migration. Most common policies that you should discuss with the target organization business are:
- Multi-factor authentication: verify your organization's current MFA policies with source and target. You might want to change the allowed second factor types or maybe use OATH hardware tokens. Also, passwordless sign-in with FIDO2 hardware tokens and Windows Hello for Business could not be configured in the target tenant.Discovering all workloads and data can be a pain, but it’s the most important thing for your organization's Tenant to Tenant migration project. I personally use reporting tools, PowerShell scripts, feedback from the community, and of course many internal meetings with all necessary business and application owners, and stakeholders. Write everything down in a project plan with details about every workload as this will help immensely to get things done. In Part 2 of this blog post series, we will deep dive into the migration itself and what tools could be used to move your workloads and data.
While ENow is not a migration company, our software does enable IT Pros to assess their organization's readiness for Microsoft 365 and accelerate their migration. In particular, ENow's solution helps organizations verify appropriate network connectivity, validate hybrid components (ADFS & AAD Connect) are setup correctly, and verify that mail routing is functioning.