Cross Tenant User Migration Approach and considerations

In any Tenant 2 Tenant migration the migration approach you have to consider based on:

• ·       Migration Tools
• ·       Communication/ Work clusters
• ·       User and shared data

The combination and dependencies of the above will guide you to the best possible decision, how you migrated a tenant and merge it into the target environment.

Migration of data is time consuming. We explained the tenant limitation (throttling) in a chapter above. Nevertheless, pre-loading of data into the target tenant is crucial including the sequence required for planning.

 

Migration Tools

There are multiple vendors on the market providing tools, tool sets. They either run on-premises, in Azure or have developed their own cloud-based solution.

Principally you will consider a mix of different tools and vendor. Most companies run a hybrid environment. This is in most cases for the users and groups synced between the on-premises Active Directory towards Azure Active Directory.

Having an approach for users and groups via the leading identity system, Active Directory on-premises, it further requires matching cloud users between the two tenants.

Here is small list of vendors:

• ·       Quest (on-premises AD / Exchange and cloud)
• ·       ShareGate
• ·       AvePoint
• ·       App4Pro
• ·       Skykick
• ·       … many more

Be advised, there is no such thing like a “suitable all in once” tool.

 

Possible Migration Approaches

The migration approach has several dependencies, I like listing here:

• ·       Number of cloud users
• ·       Number of M365 groups
• ·       Usage of M365 Groups (mostly with or without Teams)
• ·       Data volume (GB/ TB)
• ·       External Guest Users
• ·       Communication preferences within the company

Depending on the above listed consideration, there are two possible approaches for your migration. Those both I will explain in the two following sections.

Why this is all so challenging finding the right approach?

This is commonly due to complex technical and user experience setups during the co-existence phase. The challenges I list below:

·       User do not want working with two accounts, one in the source and one in the target.

·       Teams do not allow a shared SIP address space
(The SIP address can either be used in source or target, but not in both at the same time)

·       Managing temporarily Guest User Access for migrated users into the source tenant or vice versa is complex and very time consuming

·       Using Guest Access has a negative impact on user experience

 

Note:
Whatever approach you chose, how long you do your planning phase, there will be no perfect solution. A T2T migration will definitely interrupt the user experience and business flow.
Either migrated as fast as possible, wherever possible. Or try the communication cluster approach with a longer co-existence phase.

 

Communication Cluster

A communication cluster is group or area of users internally and maybe external guest users. Those groups/ clusters are in frequent or important close communication and joined work.

From the prospective of user experience, but not limited to this, also for fast and reliably corporate work, you might want to migrated those groups jointly together. Jointly together does not only include the user and their personal data, but more their shared data. Shared data include the entire M365 shared services, like Teams, SharePoint, Yammer, Stream, Power Platform and many more.

The main challenges occurring are pre-loads and service dependencies.
More, identifying those communication cluster can be very challenging. I personally had customer having more M365 groups than users. In those difficult cases, it is nearly impossible identifying those clusters. Here it only helps conduction interviews based on departments and work structures.

Ideas for communication cluster are not only departments but M365 groups too.

As an example:
Like the department development might work very closely with a prototype and a the purchase departments. You could identify those base on interviews, departments entries in AD but also based on M365 groups.
Further the challenge here is, purchase departments will also work with other departments. This is the ”chicken vs. egg” problem.

Best is, if your customer and you could define KPI’s. This will help you making the right decision.

 

Segregated user/ data approach

This approach will either migrate all shared data or user and their data first and completely. While, if the shared data is migrated based on M365 groups and includes services, like SPO/OneDrive, Exchange Mailboxes and Teams, other services might go batched. Batching includes services like standalone SPO site, standalone Planner, Yammer, Streams and more.

The question to be asked is, if you migrate users or shared data first. Here too, there is not generic answer. But, if you consider the approach users first, they can work with two accounts. This implies that the source cloud user account stays active, but limited to shared services only. The user shouldn’t work with personal OneDrive, Teams (Chat/ Calls) and Exchange any longer. The source users account is used only for access to the not migrated shared services.

The opposite is valid for shared data first. The target user account shall not be used for personal services.

This is important due to none of the migration tools has the proper intelligence for data synchronization. Data can only be “copied”. The most algorithm can identify “newer” data only based on the creation/ change date.

The means, if a user is migrated first, set the source to Read-Only for personal services. This is difficult if you start with shared data migration first and you want to set personal data to read-only.

As an example, if a user will continue using both tenants and a migrated document is changes on both sides, data of one side will get lost. Meaning: if a migrated word document test.docx is changed in source on April 1^st and in target on April 2^nd, a delta migration would NOT overwrite the target documents. Opposite, if a source document is changed on April 2^nd and the target was change on April 1^st, the target document will be overwritten and data lost occurs.

 

Planning the migration approach

We learned so far, that none of the approaches themselves will be the truth. You must do a best effort approach for your plannings. It might either be one of the approaches or a combination. Remember, every customer for a T2T migration is different. The user experience and business needs will drive your optimized decision.

In the user adoption chapter of this document, you will learn how to consider best.

Important task is defining procedures setting services to READ-ONLY and using Banners, restricting and or informing users of the migration stage.
This is important planning and executing data pre-load. While services are pre-loaded make sure those services AREN’T used.

An example of pre-load and migration workflow cloud look like this. We also recommend making use of an Migration Control Tool. Working with Excel list can work, but is mostly limited to 1.000 users. Most important beside controlling the migration itself, is sending proper user communication.

During the co-existence user must be able working probably in both environments, as said. Doing so and the solution feasible is, using the M365 WebApp. I have illustrated the use for Teams, Teams Desktop Client and Web Client.

Highlighting the complexity for users during co-existence, I illustrate the challenge during a clustered vs. segregated user migration approach. During a migration you will batch users for migration days (cut-over day). There is a maximus amount of users you can cut-over per day. During the past we have seen a number between 200-1000, the average is 600 users/day.

This depends on several factors:

• ·       Total number of users
• ·       Size of all data
• ·       Time gap between pre-load and cut-over delta sync

·       Service to be migrated
(personal chat message are extremely slow to be migrated, and might slow down the entire migration – option is: migrating chat at a later point of time)

·       Physical user location and time zone

A big bang migration might not be suitable for a tenant 2 tenant migration. Exception is; if you migrated users without their data and try coping those over at a later point of time. (But stressed again: it might cause inconsistent data if a source and target file has changed)

Further, with the numbers above you can grasp, that a communication cluster migration is very much limited to the maximum amount of users being migrated on a single day.

Regardless which method you decided for, external users (partners, vendors, clients) need to be aware of the migration and the chosen scenario. If you decided for communication cluster migration, the impact for external users might be more difficult compared with the segregated approach.

Communication Cluster Migration:

Segregated suer/ service Migration:

Generally it is recommended using the Web Clients for the source account upon the users personal migration, accessing data not yet migrated.

 

At least with the different access methods (Desktop vs. Web), there is a clear process for accessing data. The user experience compared between both paths, is very similar.

For external users it more difficult know where users or data exist. This is part of your corporate communication, how and when those users are informed. Nevertheless, the individual users ahs responsible too working with external users and help them staying connected.

Teams Desktop Client:

Teams Web Client:

Especially for Teams, where the SIP Domain Address isn’t migrated until the last service or at least all services depending on the SIP Address, the DNS Domain, it makes sense using the Web Client. There are scenarios where it’s important being reachable by the not migrated/ switched DNS Domain Name. If you are having external communication, you want to be reachable as long as possible via the original DNS name, not only for Teams but also for like Exchange. While Exchange can make use of Address Rewriting, SIP cannot utilize this possibility. Furthermore, the Web Access allow you collaborative work with users / or service not yet migrated too.

Again, and I emphasize this frequently, make sure the Change & Adoption team has time and is fully aligned with the migration approach, informing and training the users for this co-existence phase.