Cross-Tenant (Tenant to Tenant) Migration Consideration and Planning Guide

 A cross tenant / tenant to tenant (T2T) migration also named sometime cross-tenant migration can be introduced during merger and acquisitions of companies. Hereby a tenant, local or geo-tenant will be integrated / migrated into the corporate target tenant.

Cross Tenant Migrations are very complex and time consuming. Complexity can even further increase if the migration tenant is in a hybrid configuration. Time consuming, especially due to strict performance limitations in reading from and writing into a tenant. 

This MUST not be underestimated !

 

This first blog article, will help you taking all consideration into place.

 

General Technical Aspects:

•       System accesses and read permissions for external migration staff as well as service accounts for migration tools require a structured and early alignment with Security. Limitations will cause technical errors and misunderstandings during migration design and rollout. Migration tools are using elevated permissions extensively.

•       Unidentified data throughput and M365 tenant throttling issues can significantly extend estimated migration timelines. Migration pilots facilitate planning reliability and validate respective assumptions.

•       Infrastructure Readiness (Connectivity, Servers, Certificates, Firewalls etc.) needs to be checked once all technical requirements for migration have been defined. Customize readiness checklist to source and target environments.

•       Stronger policies may need to be enforced when moving from one tenant to another, e.g. MFA is required in the new tenant or password policies are stricter. Map policies and educate users on target environment requirements.

•       Change and Adoption plays a very important role at this stage of the migration, especially preparing the users for different possibilities and behaviors, as well as culture in their new tenant.

Advice: implement very early in T2T project the following rolls

•      Client and delivery stakeholder
•      Project management team from all three sides
•      An very experienced global Solution Architect
•     A Change & Adoption team from all three sides

 

Azure Active Directory and Identity:

There might be several migration and technical paths. Migration with hybrid (common) Active Directory structures require a careful analysis and planning. This is especially valid for M365 Groups. While not all groups are sync from or into the local AD infrastructure. This implies a tow path migration, from AD to AD and from AAD to AAD. The complex part is, filling the M365 groups with users synced from AD.

 

•       AD migration readiness is complex and touches several areas, e.g. E5 license assignment after user is provisioned, sync user into cloud within hybrid environments. Customize AD readiness checklist to source and target environments and define clear responsibilities.

•       Users with already existing account in target should be cleaned up to ensure that there is only one account existing in target.

•       Also clean up by deleting accounts of users that have left the organization.

•       Detailed AD discovery in design phase is reasonable, requires respective admin rights (read accesses).

•       Migration tool licensing should include a buffer to cover new joiners over project timeline or group objects (distribution or security groups) that are discovered at a late point in time. An early and comprehensive discovery is essential.

•       Video/ Voice device ready and compatible with target systems. SBC’s connected with Direct Connect.

 

Hybrid Environments:

•       AD migration is more complex than just user objects migration (e.g. permissions or DLs residing on-premise and in the cloud).

•       Migration tooling faces several challenges with hybrid environments. Tool suites need to be checked extensively. MFA can be a hinderance for tooling.

•       Evaluate the need for SID History migration to keep a user's access to the environment in source (e.g. legacy apps, certain folders on-prem).

 

Collaboration and Social:

Microsoft M365 tenants involve several services, collaboration & social are mail SharePoint Online, Streams, Yammer and other service related

•       Apps embedded in Teams and SharePoint sites can partly not be migrated with migration tools. Some apps might also not be available in target due to policy reasons. Run impact analysis and define remediation actions.

•       Migration of personal chats in Teams require an extensive amount of time long, license validity duration might not be sufficient.
Ideally do not migrate personal chats or alternatively migrate as archive at the end of user-centric migration. Teams channel chats pose no such issues.

•       Reduce migration data volumes by defining clean-up criteria, e.g. for sites w/o owners, sites that haven't been touched for 6+ months. Abandoning version histories also reduces data volumes.

•       Files in SharePoint sites that are deleted or moved after pre-load and before delta will re-appear in target -> recommendation to pre-load and cut-over in waves (and not big bang) to reduce time gap between completed pre-load and delta. This also reduces delta timelines, but takes additional effort to set up, cluster and manage waves.

•       Microsoft Stream migration deals with large data loads. This can be reduced by e.g. excluding personal videos.

 

Personal Services:

Direct user related services are Exchange Online, OneDrive for Business and Teams. Whereby Teams is another complex migration in itself. You not only have shared service, like Teams Channel, you also have the personal service, like chat and Enterprise Voice.

This chapter I will focus on in a dedicated blog.

Further, Teams also include collaboration, like SharePoint, Planner, Wiki, Apps, OneDrive and many more. Enterprise Voice is the second challenge, where you not only need to consider phone number to be migrated, but also Voice service like Call Queues and Auto attendants. Last you will have devices like phones and conferencing.

• ·       Exchange Online must have throttling removed, or reduced. This is a support request to Microsoft. Access to Shared Mailboxes are complex to identify and highly impact the migration sequence. If Shared Mailboxes are M365 Groups service, you also need to consider access to SharePoint Online.
• ·       Teams Chat migration take an extreme amount of time, nearly inconsiderable.
• ·       Teams Channel is access in a T2T migration is very complex to manage
• ·       OneDrive for Business can include a very huge amount of data. SPO is extensively throttled and will slow down your user migration significantly.
• ·       Legal Hold users might require to be migrated in close alignment with the legal department.

 

Rollout:

•        Identify all Legal Hold users early and define their requirements in close alignment with Legal departments.

•       Proper Mission Control tool with migration load batching (for users and shared services), automated mass communications and migration progress reporting facilitate the mass rollout significantly.

•       Migrate only 4 days/week plus fixing day. Do not migrate on weekends to balance support workload.

•       A dedicated rollout manager in the source organization should be made available for the project. The rollout manager should have full insights into the organizational structure and a solid connect into the business to understand induvial requirements.

•       Migrate Power Platform users in an early batch so that they have sufficient time for their manual migration activities and for issues resolution.

•       Elaborate clear and full business requirements for rollout planning, including blackout dates, freeze periods, application dependencies, VIP lists, etc.

Project Governance:

•       Clear strategic migration directives need to be defined at the beginning, e.g. UX vs migration time/cost, data consistency. Stick to strategic directives to avoid substantial changes/replanning. If changes are required, assess impacts first before action is taken.

•       A clear picture regarding License Grace Period is required for migration planning. Have required discussion with Microsoft, including post grace period license requirements.

•       Define a clear cutover from project to operations (e.g. user lifecycle) to avoid misunderstandings regarding responsibilities.

•       Take decisions swiftly and in a structured manner. One decider per workstream with escalation structure upwards to SteerCo.

•       Pilots are always bumpy, technically and user experience-wise (due to first real-life testing of tools, environment, policies etc.). Don't expect a premium experience for pilot users and manage expectations accordingly.

Important Advise:
Engage with Microsoft very early, the licensing grace period is only 90(180) days. Those days are definitive to less for migrations of 10.000 users an above.

I’m a Global Solution Architect in several T2T Migrations with Avanade ASG. We have a very strict frame work in-place managing those complex and time consuming projects.

It is highly advised not taking a T2T Project on the easy side.

Last but not least we have Power Platform. This is purely software development. There is NO way that those Apps could be migrated by a 3^rd party vendor. The client must have a very well implemented documentation for each and every app developed. This is mainly not the case.

Therefore, I recommend identifying the app owner early and engage them into the project. They must migration Power Platform by themselves.

 All Tenant to Tenant Migration required staging and Pre-Load of data for a smoother migration. The illustration below will give a simplified overview of how this migration can be scheduled.

Most migration task will be handled by a migration tool. There are different vendors on the market. I can’t recommend any vendor, as all have their pro’s and con’s. You will mainly chose several vendors for different tasks. This is recommended, as there is no one yet having the all-in-once tool.