As defense companies pursue CMMC compliance, one key step is migrating from a non-compliant commercial cloud into a secure cloud environment like Microsoft 365 Government Community Cloud High (Microsoft 365 GCC-High).
In this blog, we will discuss an often-debated question: what is the best approach for a tenant-to-tenant migration: phased or single event?
After reading, we think you'll agree: there is a clear winner.
Before diving in, let’s discuss what a tenant-to-tenant (T2T) migration is. For the context of this blog, a T2T migration can be defined as moving data, users, and/or domains from one Microsoft 365 tenant to another. Driven by compliance requirements, mergers, acquisitions, or reorganizations, this process involves navigating unique challenges and making key decisions.
With extensive experience managing and executing hundreds of migrations for organizations of all sizes, I’ll outline the key pros and cons to help decision-makers identify the best solution for their needs. Let’s begin!
Phased vs. Single-Event
When planning a T2T migration, a key decision is choosing the right approach for your organization. You have two choices:
If you're planning to retain the same vanity domains (i.e., contoso.com) in your destination tenant, this content may not be relevant, as a phased approach will cripple mail flow. On the other hand, if you're moving to a new vanity domain, a phased approach is technically feasible—but as you’ll soon discover, it’s not the recommended strategy in most situations.
The most important goal with any migration is: DON’T BREAK THE BUSINESS!
Achieving that goal requires careful attention to user experience throughout the migration process. With phased migrations, the user experience remains very similar irrespective of data groupings (i.e., personal data first, department at a time, etc.). So, for the sake of this blog, we will focus on the distinctions in user experience between phased and single-event migrations, instead of the differences in phased approach groupings.
This blog is a deep dive. If you don't have time for that, or just need a takeaway TL;DR version to send to your boss, this overview is for you:
Here's the deep dive:
Microsoft Entra ID, formally known as Azure Active Directory is Microsoft’s cloud-based identity and access management solution. Entra ID includes many features, but we will be focusing on the User Management / Identity piece.
The main reason an organization uses Microsoft 365, is to enhance collaboration and communication, not stifle it. This means users are typically working cross-departments, cross-functional areas, and cross-projects to improve productivity. For this reason, data within a tenant is typically not structured in such a way that will allow for clean lines for groupings of data.
Let’s say you decide to move one department per migration phase to ensure users that work in the same department can continue to collaborate in the destination with minimal interruptions.
Sounds great right? Not so fast.
What about the HR site in the source that didn’t get migrated? Or the IT site that contains guides for end users that didn’t get migrated? How will users in the migrated department access constant that has yet to be migrated? That’s right, they have to login using their old identity to access that information. This means that until all content is migrated, end users will need to maintain two different identities that provide access to each environment until all phases are complete.
To further drive this point home, think of the following groupings of data. All these items would need to be cross-referenced with each user and if any overlap exists, that data would also need to be moved at the same time as their department move, otherwise, two identities are required.
Additionally, until the domain is moved, mail-forwarding is typically used from the source to the destination. However, if an end user that has been migrated receives an encrypted email to their source mailbox, and that email is auto-forwarded, the mailbox it was forwarded to cannot open it. To work around this issue, you can setup autoreply’s to let external recipients know you have a new email address (which will work sometimes) or end users will need to login to the source mailbox to open the email. To ensure nothing is lost, end users will need to have access to both mailboxes using both identities until all migrations are complete.
With a single-event migration, users will lose access to their source account (unless an exception is needed) and will only have access with their destination account, leaving them with a single identity.
When it comes to devices, regardless of the migration approach, end users’ desktops/laptops can only be registered/joined to one tenant at a time. Once a device is registered/joined to a tenant, there isn’t a way to “migrate” the device. Devices must be disconnected from the source and reconnected to the destination.
With a phased approach, it is recommended to unregister/disjoin desktops/laptops immediately following the migration of the users Mailbox / OneDrive. This way, the user’s devices can be properly connected to the new tenant and can use the client applications on their device.
The same would apply for mobile devices, as soon as the users Mailbox / OneDrive data is fully migrated, the device should be disconnected from the source and reconnected to the destination.
If Windows devices are currently Hybrid Azure AD Joined, a process will need to be built to switch devices from one tenant to the other as needed per phase. This process is not trivial, but it is something Summit 7 has executed with success. The main benefit of maintaining your hybrid configuration is that it will not require a new Windows Profile on the device.
Figure 2: Entra Hybrid Joined
If Windows devices are currently Entra Joined, they will need to be disjoined from the source and joined to the destination, which will require a new Windows profile.
Figure 3: Entra Joined
Once user’s devices are fully connected to the destination, they would use the browser as needed to access content in the source environment and should use the client apps to access content in the destination environment.
With a single-event migration, all devices should be disconnected from the source and reconnected to the destination at once. If this isn’t possible, we always recommend using the browser to access the tenant while devices are being reconnected.
For Hybrid Entra Joined devices, the Service Connection Point (SCP) can be updated to point all devices to the new tenant. Additionally, devices should stop syncing to the source and start syncing to the destination via Entra Connect.
For mobile devices, the user experience will be the same as a phased approach, just simpler for administrators as they don’t have to retire in batches based on which users are migrating. With a single-event migration, we typically bulk retire devices, revoke primary refresh tokens, and block source logins via script to prevent end users continuing to accidently access the wrong environment. Exceptions are made on an as-needed basis.
Key Takeaway(s)
When it comes to connectivity to Microsoft 365, a single identity is used per browser profile per cloud environment. If you attempt to use two different commercial accounts in the same browser to login to https://portal.office.com, you will run into issues.
To work around this, end users can be instructed to use multiple browsers, IE Chrome to access one tenant and Edge to access the other tenant until all migration phases are complete. Or, end users can be instructed on how to use browser profiles, that way they can create a profile for each tenant which will allow you to use a single browser to access both tenants.
For a phased migration, instructions need to be sent to each end user to walk them through how to use multiple browsers or browser profiles to maintain access to both environments until all migration phases are complete. This will lead to end user confusion and help desk tickets.
From an administrative perspective, there isn’t anything that can be done to avoid the need for two identities. You could clear the browser cache pragmatically, but that wouldn’t help this issue, as they will need to maintain their login to the source to access data that hasn’t been migrated yet.
With a single-event migration, scripts can be deployed via GPO to devices to clear browser cache, clear Teams cache, and create a new Outlook Profile to assist with re-authentication to Microsoft 365 GCC-High. Microsoft also provides scripts to help with resetting of the Microsoft 365 Apps for Enterprise activation state. If a script isn’t an option, as mentioned previously, logins to the source will be blocked and refresh tokens will be revoked. This will require end users to sign back in using their new UPN via the browser and client applications as needed.
Reference Link:
Regardless of a phased or single-event migration approach, it is critical that SharePoint Online content is migrated well in advance of the weekend or point in time in which users are “cutover” into the new tenant. This is primarily due to the sheer amount of data being migrated and the time required for our migration tooling to move it given platform throttling limitations.
This is required for several reasons:
A phased migration presents complexities due to SharePoint sites being shared workspaces. When migrating via a series of user phases by function, department, or division, it is straightforward to segment users when it comes to personal data (OneDrive and Mailbox).
However, sites and shared workspaces don’t generally conform well to separation into a series of phases. A few examples:
Once migration phases begin, you end up with a scenario in which some users (e.g., phase 1) have access to sites/shared workspaces in the destination, whereas other users (e.g., not yet migrated) are still collaborating within those same sites/shared workspaces. This presents a few key problems:
With a single-event migration, content residing within shared spaces (e.g., sites) is significantly less complex.
Users will collaborate exclusively in the source tenant while all content is being migrated (copied), validated, and prepared for a single cutover event for all users. Since users will not ever actively collaborate within both the old (source) tenant and the new (destination) tenant, data integrity issues are minimized.
With a single-event migration there is more content to reason over with incremental migration syncs during the cutover weekend outage.
This section focuses on the Teams Chat user experience differences between Phased and Single-Event migration approaches. For the actual Team (Site, Channels, etc.), everything mentioned in the Collaboration Workspaces will apply.
For one-on-one chats, if an end user is currently chatting with someone internally in the source tenant and one of the users in the chat is migrated, the user will need to switch back and forth between identities to continue to chat via Teams with the non-migrated user, or Federated chat can be configured to work between the tenants. With Federated chat enabled, end users can see two identities for the same user, one currently in the source, and one in the new tenant, leading to communication confusion if they message the wrong account.
Migrating everyone as once will allow all chats to be migrated and users to continue to chat as they do today.
OneDrive is one of the simpler workloads, but complexities still exist depending on the migration approach.
With a phased OneDrive migration, end users will maintain all their files and regain the ability to OneDrive Sync once their device is reconnected to the new tenant. However, depending on how the phases are determined, internal sharing links can become a problem.
If an internal user that has a file shared with them doesn’t migrate over with the other internal user that owns the OneDrive, they will maintain the ability to modify files in the source OneDrive. This will allow for the same file to be modified in the source at the same time a file is modified in the destination, creating a headache for the owner of the file.
One solution to this problem would be to turn-off the OneDrive feature for the users in the source that have already been migrated, but then, the users that are still in the source, don’t have an easy way to collaborate without moving the file. Another solution could be to set the source OneDrive to read-only, but the same collaboration limitation applies.
With a single-event migration, all OneDrive files and internally shared links will remain intact, users will be able to continue collaborating on shared files as needed.
This section will focus on the Exchange Online user experience.
With a phased Exchange migration, like other workloads, the experience will depend on the approach used. With each of the options, mail-forwarding will be critical, as mailboxes are moved in each phase, forwarding will need to be setup from the source mailbox to the destination mailbox to make sure mail flow continues to work as expected. When users reply, they will only be able to reply with their new email address as the other domain will not get moved until the end of all phases.
When determining how to group users when it comes to Exchange, the following items will need to be considered:
All mailboxes, lists, groups will be moved together. Access to shared mailboxes will remain intact without users having to switch between identities.
The best approach for your tenant-to-tenant (T2T) migration depends on your organization's unique needs, scale, and existing dependencies. That said, after overseeing hundreds of successful migrations, I strongly recommend a single-event migration. If time and resources permit, using an extra vanity domain to conduct a pilot single-event migration is ideal. Testing with a small group—5-10 user accounts, Teams, and Microsoft 365 Groups—will help you fully understand and document the process before scaling up to the entire organization.
For those transitioning from an on-premises environment, a phased approach can be a practical solution. It allows users to manage a single identity with minimal disruption, making the migration process smoother and more manageable.
If you need a T2T migration, our team is here to help. Fill out the form below and someone will reach out to help you plan a migration that is easy on your users and brings confidence to your leadership.