Choosing the Best Microsoft Tenant-to-Tenant Migration Approach: from M365 Commercial to GCC High

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.  

What is a Tenant-to-Tenant Migration?

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: 

• Phased – A phased migration approach is when content is moved from the source environment to the destination environment in manageable batches, chunks, groups, waves, phases, etc. You could group by department, function, or even by who has access to the data (e.g., personal data first such as OneDrive and Mailboxes and shared spaces (Teams, Sites, Groups, etc.) last.). This approach is typically done a few times a week over several weeks.  

• Single-Event – A single-event migration approach is when all content is moved from the source environment to the destination in a single, coordinated effort. This is also known as a Big Bang migration. It is typically done over the weekend (size depending) and when users come in Monday, all content is in the destination environment. 

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. 

How Do You Choose What the Best Tenant-to-Tenant Migration Approach Is? Consider the User Experience. 

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:

The Top 7 User Experience Considerations When Choosing a Tenant-to-Tenant Migration Approach

User Experience Consideration #1: Entra ID  

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. 

Entra ID: Phased 

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. 

Figure 1: Two Identities, One User

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. 

• Shared Mailboxes 

• Delegate Access 

• Shared Calendars 

• Distribution Groups 

• Security Groups 

• SharePoint Sites 

• Microsoft 365 Groups 

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. 

Key Takeaways 

• There will be a coexistence period where users juggle two identities to two different production environments. 

• You will be unable to block logins to the source as users will need to maintain access to both environments. 

• Encrypted emails can be a challenge. 

Entra ID: Single-Event 

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. 

Key Takeaway

• Users maintain a single identity avoiding confusion post-migration. 
  

User Experience Consideration #2: Devices 

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. 

Devices: Phased 

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. 

Key Takeaway(s)  

• Post-migration device re-connectivity is more complex. 

• You will need to target specific devices with each migration wave. 

• Users will need to follow instructions for how to use a separate browser/profile to access data in both tenants at the same time until all phases are complete. 

• Source content can only be edited in the browser as the local client apps should be connected to the destination tenant. 

Devices: Single-Event 

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) 

• Post-migration device re-connectivity process is the same as a phased migration. 

• The device reconnection process will be simpler from an administrative perspective. 

User Experience Consideration #3: Browsers 

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. 

Browsers: Phased 

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. 

Key Takeaway(s) 

• End users will be required to juggle multiple browsers and/or browser profiles using multiple User Principal Names (UPNs) and potentially multiple MFA solutions. 

Browsers: Single-Event 

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. 

Key Takeaway(s) 

• Potential administrative assistance available via PowerShell Scripts. 

• Simplified end user experience. 

Reference Link:

• Reset Activation State – Reset activation state for Microsoft 365 Apps for enterprise - Microsoft 365 Apps | Microsoft Learn 

User Experience Consideration #4: Collaboration / Shared Workspaces (SharePoint Online, Microsoft 365 Groups, Etc.) 

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: 

• Provides the tooling time to migrate the bulk of the data 

• Allows our team(s) to review and vet the accuracy of what’s been migrated via spot checks, review of tooling logs, etc. 

• On migration night, we’re only performing an incremental migration of changes/deltas that have occurred since our last migration pass – significantly reducing the time required to iterate through all content being migrated. 

Collaboration / Shared Workspaces: Phased 

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: 

• Communication/publishing sites which all users have/require access. 

• Cross-functional sites or workspaces used to provide collaboration by contract, proposal, etc. 

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: 

• It will be complex to plan out user phases in such a way to minimally impact cross-functional sites and collaborative spaces. 

• Once migration phases begin, it’s very likely you will have sites/shared spaces where active collaboration is occurring in both the source and the destination. 

• • Already migrated users – actively working in the new site 

• • Not yet migrated users – still collaborating in the old tenant. 

• • • This is also true for other collaboration tooling such as Planner Boards, OneNote Notebooks, etc. 

• Once users land in the destination tenant (e.g., phase 1), they will be able to access content where they have appropriate permissions. Since all content will be being migrated in bulk in advance of any phases/cutover dates, there is a possibility that users begin accessing/inspecting/modifying content that is still in-progress and is not yet ready/nor was included/slated in the following phase. 

• • In this instance, data integrity issues are likely as our migration tooling will not understand/react well to content being actively edited within both the source and destination. For example: 

• • • User A (migrated in Phase-1) opens a document that resides in a site that hasn’t been fully migrated yet or is still being actively worked on in the destination. 

• • • By opening, User A flags the document as being modified. 

• • • User B hasn’t migrated yet but has worked on the same document in question. Since User A opened an old version of the document in the destination, the document shows as “newer” and User B’s latest version in the source tenant doesn’t get migrated as expected. 

Key Takeaway(s) 

• Complexities in planning user phases to best account for cross-function sites and workspaces whose audience doesn’t fit neatly into a specific department, function, etc. 

• Strong likelihood for miscommunication or inefficiencies if the audience of shared spaces is split and users continue to collaborate in the now duplicated space that can be actively used in both the source and destination environment. 

• Possibility of data integrity issues as users open/edit/modify documents and list items that exist and are available to users in both tenants. 

• Essentially, once users are allowed access into the destination tenant in phases, there will be content that no longer has a single source of truth as we can have active collaboration in both places. 

Collaboration / Shared Workspace: Single-Event 

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. 

Key Takeaway(s) 

• The migration of shared spaces like SharePoint Online sites present considerably less complexity and risk in terms of data integrity and race-condition issues in comparison to a phased migration approach. 

• Since more data will be reasoned over within a single-event migration, some additional work is needed to ensure that all content can be migrated within a single outage period. 

• Given the amount of data being migrated, migration prep will include coordination with both Microsoft and migration tooling to ensure minimal throttling. 

User Experience Consideration #5: Teams Chat 

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.  

Teams Chat: Phased 

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. 

Key Takeaway(s) 

• One-on-One chats will be disrupted as migrated end users will try to Teams message a non-migrated user in the destination, leading to non-responsiveness. 

Teams Chat: Single-Event 

Migrating everyone as once will allow all chats to be migrated and users to continue to chat as they do today. 

Key Takeaway(s) 

• The Teams chat experience will continue to work as it does today. 

User Experience Consideration #6: OneDrive 

OneDrive is one of the simpler workloads, but complexities still exist depending on the migration approach. 

OneDrive: Phased 

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. 

Key Takeaway(s) 

• Collaboration via OneDrive shared files will be a headache. 

OneDrive: Single-Event 

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.  

Key Takeaway(s) 

• Collaboration will continue seamlessly. 

User Experience Consideration #7: Exchange Online 

This section will focus on the Exchange Online user experience. 

Exchange Online: Phased 

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: 

• Delegate Access 

• • If a user is migrated that has delegate access to a mailbox that isn’t moved, that user will need to continue to use their source identity to access the mailbox until all migrations are complete. 

• Shared and Group Mailboxes 

• • Like delegate access, users will need to switch between identities as needed to access specific mailboxes. 

• Meetings 

• • As users are migrated, they can choose to use their source identity to attend existing meetings or resend out meeting links as needed for externally facing meetings. 

• Groups 

• • Any mail-enabled group will need to be set to allow external emails as users from both tenants will need to email the group until all migration phases are complete. 

Key Takeaway(s) 

• Access to mailboxes will require users to switch between identities as needed for all shared mailboxes and delegate access. 

• Internal and External meetings will need to be updated with a new Teams meeting link. 

Exchange Online: Single-Event 

All mailboxes, lists, groups will be moved together. Access to shared mailboxes will remain intact without users having to switch between identities. 

Key Takeaway(s) 

• External facing Teams meetings will need to be updated with a new Teams meeting link. 

What is the Best Tenant-to-Tenant Migration Approach?

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.