Five Pitfalls to Avoid during a Microsoft 365 Cross-Tenant Migration

Planning for Success

I’ve been involved in onboarding organizations to the Microsoft cloud as well as moving and consolidating them between tenancies for almost 10 years now. I’ve seen and created a lot of different top 5 or top 10 lists on this topic. For this blog, I figured I wouldn’t tackle the top 5 things to do! Why? Well, because everyone has already covered them, and they haven’t changed too much. You probably know some of those already… pilot then reassess, have a rollback plan, over-communicate and the list goes on and on.

For this list, I’ve collected some rough pitfalls for you to consider when planning your next Microsoft 365 Cross-Tenant migration project. These pitfalls (see figure 1) impact various areas in Microsoft 365, including Teams, Azure AD, Exchange Online, and Cross-Tenant integration.

Migrating Personal Chats

Multiple cloud migration tools now offer solutions to migrate Microsoft Teams 1-on-1, group, and meetings chats. The volume of personal chats swapped each day in Teams is enormous, let alone a year’s or more worth, making this newest Cross-Tenant migration workload both complex and time-consuming.

Vendors tackle the problem in different ways, but no matter how they manage to slice up this huge volume of data (i.e., abridging threads, archiving chats to files, applying age range filters), you must ask the question:

During this M&A event, is this type of user-based data critical to business operations and the bottom line?

If the answer is no, and I suspect it may be for many, then you should consider avoiding any chat migrations whatsoever. If you can’t completely avoid them, then at least seek a cloud migration tool that delivers options to filter in small chunks, such as the most recent 30 to 90 days, which has more value.

Ask yourself, in a merger, acquisition, or divestment situation, will the end-user need any of their personal chat after 90 days from the transition? How much value does it have over time? Does that value decrease as time passes?

Consider what value your end-users are gaining versus the resources and time it will take to move this newest Microsoft 365 workload. Run a pilot migration for this workload to capture the transfer velocity to determine if and how much chat could be migrated in the timeframe. Then set a reasonable range. You may also consider surveying your end-users about the value personal chats have to them in their productivity, offer them alternatives to migration, and then measure their feedback.

To understand the full extent of the challenges of migrating Teams personal chats, see Randy Rempel’s article: Microsoft Teams Private Chat Migration Challenges Explained

Creating B2B Guest accounts before you have an IAM integration strategy

When two or more organizations are merged, there is often a phase where each set of users exists in two different tenants before migrations have occurred. This phase could be days, weeks, or even months depending on the organization’s migration strategy and timelines. During the coexistence phase, it is easy for end-users in the organization to begin to utilize B2B collaboration to grant new colleagues access to shared resources. Administrators may even decide to create guest accounts in bulk to prepare for sharing scenarios for departments that require this type of access before everyone is migrated.

The problem is that when it is time to migrate a user and their data, you’ll have a possible conflict. If you just remove the guest account to clear the conflict, that user loses access to all those shared resources, and then the access must be manually re-established after the migration. Even if you convert the B2B guest account to a standard member user to retain access, this will still add unnecessary complexity and lengthen your migration project. If you want to learn more about this challenge, check out my previous blog on the topic. 

Before you begin letting users invite guests to Microsoft Teams, plan out how, and more importantly when you will migrate and/or synchronize accounts, groups, and membership between tenants. This way you may determine the best method to authorize and maintain access to shared resources before, during, and after the migrations. The following is recommended:

• Let Teams owners access their Teams to validate the content and finish the configuration prior to letting all Teams members access the Team.
• Allow migration users to migrate Teams memberships at the very end of the Teams migration.

Migrating mailboxes without delegates

If you migrate a mailbox without their delegates, then those who shared access to their mail and calendar will no longer have access after the migration, forcing the end-user to re-establish appropriate rights.

Envision an executive assistant not having access to the executive’s calendar for several hours or more! Who’s going to pay for that mistake?!

When evaluating cloud migration tools, be sure to discover how or if mailbox permissions and delegation are migrated, and under what circumstances. Often you will find that a solution will migrate delegates but only if all the mailboxes are batched together, or if the accounts are mapped in the migration tool. Some tools neglect certain permissions altogether.

When possible, pilot the migration tool you choose to verify this use case. Even if the documentation says it works, you’ll want to confirm it works in your environment. Verify all these permission types are migrated:

• Read and manage permissions
• Send as permissions
• Send on behalf of permissions
• Inbox folder permissions
• Calendar folder permissions

Using the native migration solution

The Microsoft Exchange Online Cross-Tenant Mailbox Migration PowerShell features have been in Public Preview since 2020. I am personally very grateful to the engineers and product teams that built these features; it is invaluable to Microsoft administrators. However, it has a few limitations that you should be aware of before deciding to use this solution for migrating Exchange Online mailboxes for an enterprise migration. Unless you are hiring a professional services organization to conduct the migration operations for you, then I recommend you consider these questions before starting your next large project.

1. Do you want to spend a lot of time having someone implement this feature? The native solution has a complex implementation process. Learn more about deployment here.
2. Do you have someone that can write and maintain scripts for this project? Third-party applications offer no-code solutions with easy management interfaces.
3. Do you need to filter what is migrated in the mailbox? The native solution doesn’t offer to filter, it replicates the entire mailbox just like the Exchange on-premises MRS proxy does.
4. Can you manage this portion of the migration project without a management interface? The native solution is managed with PowerShell but does offer a basic queue which is visible in the Microsoft 365 admin portal. Here is some more information on the topic.
5. Do you plan to move mailboxes based on delegates to avoid losing those permissions? The native solution requires that mailboxes with delegates be moved in the same batch to ensure permissions are fully migrated and even then, many permissions don’t migrate at all. Read more about it here.  
6. Is there a plan to reconfigure Outlook after migrations? The native solution, unlike its on-premises counterpart, does not automatically reconfigure the desktop Outlook client with Autodiscover services. For more information, read this.

My recommendation is to search for a cloud migration tool that solves or mitigates these concerns. There are vendor tools that will provide no-scripting options, quick deployments, and robust means for managing projects while migrating permissions and automatically reconfiguring desktop applications.

Neglecting to plan for Identity & Access Management (IAM) integration and continuity

All migration tools require a mapping table to pair source and target objects for various aspects of the migration to be successful. The accounts and groups in both directories must already be in place with a unique identifier to match objects for building the mapping table.

Before deploying any migration tool, ask yourself the following questions:

1. How are directory objects for both tenants going to be procured and maintained during the migration project?
2. Is there an authoritative directory?
3. Will deletions, attribute changes, and disabling of accounts be maintained between directories?
4. Have the corresponding accounts and groups now residing in the source tenant been created in the target?
5. Does each object have a unique matching attribute value to pair objects together?

Depending on the answers to these questions you may find the organization isn’t prepared to initiate migrations because they haven’t planned how to manage identities access during the transition.

I recommend during longer phased migrations that take months to complete, and even post-migration prior to a tenant being decommissioned, that organizations deploy a directory synchronization solution that can create and maintain AD and/or Azure AD objects and their associated properties in sync for as long as required.

By centralizing your identity and access management for the objects being migrated, you will eliminate excess work to add, remove, or modify objects. Centralization will also reduce the overall risk by limiting where and how objects are managed, and by whom.

This type of tool will provide you with the means to provision objects in bulk for the initial setup and then maintain normal daily directory changes such as new hires, leavers, and renames. It is critical for a good migration tool to maintain awareness of these object changes so that it does not negatively impact migration processes.

Conclusions

While these five pitfalls aren’t the top ones you may encounter during a Cross-Tenant migration project, they are nonetheless important to be aware of during planning. Always remember:

1) If Chats aren’t required, don’t move them, only move the most recent and archive the rest

2) Creating lots of B2B guests without a plan may later complicate migration processes

3) Migrate all the permissions possible

4) Don’t rely on the native mailbox migration feature for enterprise projects spanning different workloads, purchase a 3^rd party tool

5) Centralize IAM by designating the source Azure AD as authoritative (for migrating objects) and establishing directory synchronization between source and target