Microsoft M365 Cross Tenant Migration Book

© Thomas Poett Microsoft MVP, 2023
GUIDE TO
MICROSOFT CROSS-TENANT
MIGRATION
(TENANT-2-TENANT)
Version 1.1 (Feb 2023)
Master all challenges with Microsoft Cross-Tenant Migrations.
Dedicated sections to Microsoft TEAMS CROSS-TENANT Migration.
The guide includes Teams Team/Channels, private/ personal chat and Enterprise Voice
(Direct Routing)
.
Big credits to my teammates from Avanade (Collaboration team, Rollout team, Change &
Adoption team) and Randy Remple providing screenshots with permission from Quest.
Written and copyright © by Thomas Poett (MVP Office Services and Apps),
Solution Architect and technical Pre-Sales for Workplace Infrastructure at Avanade

Foreword
In this cross-tenant/ tenant-2-tenant migration book, I guide you through the holistic approach,
which in deep exercise of Team Voice.
I’m working as an Enterprise Solution Architect for Cross-Tenant migration, leading teams with more
than 40 persons involved.
Technically there are many more aspects, like 3rd
party tools vs. Microsoft own solutions and scripts
to be written. This book provides you an inside but not providing scripts and detailed configuration.
Scripts and configurations are very much an individual approach for each cross-tenant migration.
Two very special chapters will be released in 2023, handling and working with Guest User Access and
Change & Adoption approach. Both are not only technically important but require a deeper look into
their dependencies.
Working on an end-2-end overview, technical considerations and understandable working template,
this Migration book, it was work consolidated during the last 1 ½ years.

Contents
GUIDE TO MICROSOFT CROSS-TENANT MIGRATION (TENANT-2-TENANT) ...................................................1
Foreword.................................................................................................................................................2
Cross-Tenant Migration Consideration and Planning Guide ..................................................................5
Tenant to Tenant Comparison..............................................................................................................11
Technology – what is different between source and target.............................................................11
User Experience – what changes imply for users .............................................................................11
Consider Computer Migration..........................................................................................................12
Azure AD joined ............................................................................................................................12
Migration of Autopilot devices .....................................................................................................13
Enable Enterprise State Roaming..................................................................................................14
Intune tenant settings export/ import into the new environment ..............................................14
SCCM.............................................................................................................................................15
Conclusion and Advice Computer Migration................................................................................15
Cross-Tenant Teams Migration.............................................................................................................16
Summary and approach for a Teams Cross-Tenant Migration.........................................................19
Enterprise Voice Teams Migration for Tenant to Tenant .....................................................................21
Calling Plan – Microsoft operates your PSTN ...................................................................................22
Managing Cross-Tenant phone number porting ..........................................................................22
Scheduling Cross-Tenant phone number porting........................................................................24
Operators Connect – hosted and managed SBC booked via M365..................................................25
Direct Routing – your own SBC with a PSTN Provider ......................................................................26
Handling Call Queues and Auto Attendant during Cross-Tenant Migration ....................................31
Teams Personal Chat Migration............................................................................................................32
APIs used for chat migration.............................................................................................................33
Migration Options for Teams Chat Messages Destination...............................................................35
User Experience Teams Chat Massage visualization in Target Tenant.............................................36
Realistic approaches that need to be considered in the planned migration schedule ................38
Personal Chat Migration into Azure Data Lake.................................................................................40
Another approach, rudimentary described in the white paper is, migration or better said
exporting Teams chat messages into Azure Data Lake solution...................................................40
Teams Channel Migration.....................................................................................................................41
Personal Data migration Exchange and OneDrive................................................................................43
Data Pre-Load ...................................................................................................................................43
Throttling ..........................................................................................................................................43
Conclusion.........................................................................................................................................44

Co-existence DNS Domain issue ...........................................................................................................44
Cross-tenant Shared DNS Space (Native Cross-Tenant Domain Sharing for Exchange Online) ......46
Cross-Tenant Domain Sharing Configuration................................................................................46
Primary SMTP Address Assignment..............................................................................................47
Cross-tenant Identity Mapping (preview) approach: ...........................................................................48
Cross-tenant Mailbox migration approach:..........................................................................................49
Free & Busy Sync during Cross-Tenant Migration ............................................................................50
Organization relationship in Exchange Online..............................................................................50
This feature is named: Organization relationship in Exchange Online ...............................................50
Free/Busy sync cross-tenant with Exchange Online.....................................................................51
Cross-tenant OneDrive migration approach:........................................................................................53
Example of our user data migration approach:................................................................................54
Meeting Link Migration for Teams....................................................................................................55
Meeting Link Migration Considerations........................................................................................55
Handling Cross-Tenant Guest User Access ...........................................................................................57
Cross Tenant User Migration Approach and considerations................................................................58
Migration Tools.................................................................................................................................58
Possible Migration Approaches ........................................................................................................59
Communication Cluster ................................................................................................................59
Segregated user/ data approach ..................................................................................................60
Planning the migration approach .....................................................................................................61
Cross Tenant User Adoption Process....................................................................................................66

Cross-Tenant Migration Consideration and Planning Guide
A cross-tenant / tenant to tenant (CROSS-TENANT) 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 white paper will help you by taking mainly 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 CROSS-TENANT 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 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 CROSS-TENANT 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 the 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 CROSS-TENANT 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 CROSS-TENANT 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 3rd
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.

Tenant to Tenant Comparison
The main head word in CROSS-TENANT comparison is the “Technology Harmonization”. Beside this,
users will experience a different M365 feature usability, this is the other side to be identified and
leads to the Change & Adoption approach.
Technology – what is different between source and target
Several topics are included in this topic, not limited to technology only but overlap with user
experience too.
Commonly we start with the licensing comparison. This might mainly restrict the usage of services or
limit the services towards migrated users. From here you analyze each service step-by-step. Not only
data / storage limitation could apply. Like in personal OneDrive, where the target could have lower
storage limits than in source.
Areas like Guest User Access, Domain restrictions, Teams federation and other B2B configurations
might lead to data migration/ usage limitations. It is advised to work with both side equally and see
how the target environment is leading and if changes must apply, how this governance can be
achieved.
Users can work quite freely in a M365 tenant, like they can create new services attached to M365
groups. This could be different in the target tenant. Not only is this a technical restriction, but also
impact the user experience intensely.
The most complex task for comparison is the AIP, labeling, policies and encryption. Matching both
sides is a project in itself. Encryption is another hassle, as the AIP encryption keys must be accessible
from the target and must be migrated while you migrated the DNS domains. IF DNS domains aren’t
migrated, it must be considered another project in a project, decrypting source data and re-
encryption during migration.
User Experience – what changes imply for users
Migrating user experience from source to target completely depends on the possibilities and feature
sets in the target environment. As an experience isn’t technical, rather than it is behavioral.
Work and human culture in the target environment might also differ from source. Only a holistic
approach will make users feel comfortable after the migration.
Compare the technical feature set per service and list the difference between source and target. Go
on with conducting interviews with the IT departments and users across the company.
You should involve two skills, technical expertise and a good adoption specialist. Both need working
hand in hand with the client.
The result will directly define the areas where the change & adoption team will work on.
For more and detailed information read the chapter “User Adoption Process”

Consider Computer Migration
Computer Migration in parallel with User Migration is not an optimal approach!
Why is this so and what are the impacts:
- It will extend your migration time line
- It might affect the Licensing Grace Period with Microsoft (becoming more expensive due to
double licensing)
- Computer Migration and Profile Migration will take time (approx. 1-5 hours)
- 3rd
party tools are required for migration
- Computers must be online during the device migration
- If Intune is used for management solutions, a reimaging might be required
Azure AD joined
For Azure AD joined Windows 10 devices, the issue is that there is no local admin on the
device. Without a local admin, as soon as the Azure AD (AAD) account gets removed, you no longer
have access to the device or it’s contents.
You must remove the device from Azure AD prior to your migration. If you are in hybrid AD, you can

simply unjoin/ remove the device from Azure AD and leave the device in the On-Premises AD only.
Here a migration is handle with a 3rd
party tool, like Quest MMAD/ RUM (Resource Update Manager)
Nevertheless, in any cases, the user profile must be migrated, else the user starts with an empty/
fresh user profile. This is an unacceptable user experience.
There is an option, but with limited user experience too. You can prior to migration, if not already
done, redirect know folders to OneDrive. Those folder e.g. are, Document, Videos, Downloads,
Favourites,…
After migration and users OneDrive migration, the know folder can be synced again.
But note: other applications might not work any longer, testing, intense testing is required.
Office/ M365 application can be reinitiated, or a tools can switch those to the new tenant target.
Another recommendation is to treat a tenant to tenant migration as if your users were getting a
new device. Make sure they back everything up and schedule a time for them to reset the device
and set up the “new” one. Unfortunately, USMT (user state migration tool) doesn’t support Azure
AD account migrations.
Migration of Autopilot devices
Upon you reset the device and it’s in (Out-of-Box-Experience) OOBE, it will discovering for an
Autopilot profile. Ensure the hardware hash is removed from the source tenant, else If the hardware
hash for the device is still into your old tenant, it will be prompted to re-enroll into the source
tenant
Device must be unenrolled prior to deletion. You need to schedule this process accordingly in your
migration plan.
In the Microsoft Endpoint Manager admin centre, make sure to export and then delete all the
devices you plan on to migrate:
Export Autopilot devices

Delete Autopilot devices
Enable Enterprise State Roaming
Enterprise State Roaming is a more sophisticated solution compared to OneDrive know folder sync.
You can manage which users are enabled for Enterprise State Roaming.
Upon have their users AAD account synced, they begin syncing Windows 10/11 settings, such as
desktop background, theme, language preferences, and other.
Enterprise State Roaming setting
Intune tenant settings export/ import into the new environment
If this will be a completely new Intune environment, one way to save time would be to import your
old settings. This won’t import the assignments, but at least all of your configurations will be the
same.
In case of this is a merger, this option is NOT available.

SCCM
This is the most complex migration you could initiate. But lets focus on the Device/ Computer
migration itself. Remember, in SCCM you will have to repackage the software packages into the
target SCCM.
If your computers are Azure AD joined, remove them from there and leave those in on-premises AD
only.
Then follow those steps:
1. Enrol the target root certificate
2. Enrol the device certificate
3. Ensure the CMG is ready if in use
4. Uninstall the SCCM source agent
5. Migrate the computer AD to AD
6. Ensure the computer is either in the LAN or VPN
7. Execute the target SCCM agent (e.g. via GPO, logon script, ..)
8. Run the Profile Migration Wizard (3rd
party tool)
9. Optional, run the Desktop Update Agent (redirect the O365 Application to target tenant)
This procedure should be done overnight and might take up to 7 hours.
Conclusion and Advice Computer Migration
Best is NOT migrating computers during the user CROSS-TENANT migration !
But if this is required, make sure the migration scheduling matches the availability of users, help
desk capacity and migration team schedule.
You need a strong team with enough manpower handing those migrations.

Cross-Tenant Teams Migration
The Microsoft Teams Tenant to Tenant Migration Guide I have separated into the several chapters.
• Enterprise Voice
• Team/Channel Migration
• Personal Chat Migration
Why Teams Migration in a tenant to tenant scenario is so complex?
First, Teams makes extensive use of other M365 service, considered as shared services. Teams uses
Enterprise Voice, with might be using Direct Routing, Calling Plans and Operators Connect. The
shared part of Teams can get very planning extensive if you need to identify Channels and migrate
them along with users. You can imagine how complex the web of Teams channel user can get.
The initial advise is, you have to setup a team of experienced teams consultant for voice, devices and
channels. This team of experts need to work very closely with the experts of other CROSS-TENANT
migration streams, like SPO, Exchange and more. You should make use of those migration strategies
and try implementing the same for Teams and their attached services.
Beside of the named service and features above, there is another topic not only for Teams but
frequently used here. This is the GUEST USER ACCESS.
Guest users need to be reinvited and sharing needs to take place again. This involved external
communication and needs to be considered early and taken into the change & adoption plan.
Labels
USER individual Services
Manual Match and Associate
(Source/Target)
SOURCE
Tenant
TARGET
Tenant
Cloud User and Resource
Accounts
User Mailbox
(along with delegates)
User personal OneDrive
User Teams Account (activation)
Voice (PSTN and Queue Membership)
Labels
While you migrate a Teams user along with his personal services, you must have an additional task
very close the main user migration switch. This is the MEETING LINK MIGRATION.
Soon a user starts working on the target tenant, the Team Online Meetings have been migrated as

they are, this implies a dedicated task for Meeting Link Migration. Else the meeting is still hold in the
source tenant.
Be aware, this could be a confusing task towards the participants. They will receive a meeting
cancelation and at the same time a new meeting invite form the user in the target tenant.
SOURCE
Tenant
TARGET
Tenant
2.) Migrated MBX incl. Calendar
3.) Run Team Meeting Migration
1.) enable Teams user (license)
Meeting URL
Re-Write
The process for possible Resource accounts, as illustrated below, follows the same process as it
designed for users.
SOURCE
Tenant
TARGET
Tenant
1.) migrate Room Mailbox
(resource) + (license)
Meeting URL
Re-Write
4.) reconnect Meeting Room
Device on migrate Resource
Account
Channel Migration and other shared service like Call Queues doesn’t make it easier. You need to
evaluate a proper, user centric schedule for those services. It is advised not to split Call Queues for
their assigned users.
Moreover, this is a close and tight migration setup for all related services at once per M365 Groups.

There are issues you need to care.
1. During pre-load of channel data and services, the channel is visible and could be seen and
used by users already
2. You cannot hide a channel
3. Private channel need to be provided before migration
4. Delta syncs aren’t possible for private channel and chat messages
5. Soon a channel is migrated you should delete or archive
6. Cross tenant access to channels is difficult to manage if not all members with access are
migrated.
M365 GROUP associated Services
SOURCE
Tenant
TARGET
Tenant
SharePoint Site
created links/ shared items
Teams SharePoint Site
(Wiki, Tabs, Planner)
Teams Initialization
(Teams, SP Hull, )
Exchange Shared Mailbox
Exchange M365 Group Mailbox
Teams Voice (PSTN) and SBC
related Tasks (manual and scripted)
M365 Groups

Summary and approach for a Teams Cross-Tenant Migration
Microsoft Teams is awesome communication and collaboration set of tools and methods. The
integration and combination of existing M365 services into MS Teams makes this migration
challenging and complex for planning and execution.
Different content types and storage locations are the major concern and will mostly lead to migrate
with a larger set of tools.
Approach:
• Teams channels with conversations and files
• Standard, private and shared (in public preview) channels
• Standard & Custom SharePoint sites in Teams
• Tab’s and App’s in Teams
• Private 1×1 chats
• Privat 1×n chats
• Planner and tasks, Wiki
• Group mailboxes
• Teams meetings which contain chats, files, whiteboards,
Need to consider/ high-level check-list:
Microsoft Teams is like the king on top of M365 Groups services. You don’t make anything wrong, if
you define a migration-in-migration project, dedicated to Teams only. The high-level check-list will
help you defining your details Microsoft Teams migration project.
• Know your source Teams environment, incl Voice and App attached application, like Contact
Centre
• Analyse what is not necessary to be migrated and can be removed or left behind
• Create the migration setup in a test tenant
• Test the accounts and run migration tests (in test and production tenant)
• Do a tenant to tenant comparison (what can / can’t be used in the target tenant)
• Run performance tests (run them in case in parallel with other migration tasks)
• Prepare a Change & Adoption plan
• Create a migration project plan
• Pilot a post migration validation

• What about Teams settings that cannot be migrated with migration tools or are not
compatible with the target tenant
With the principal plan ahead, you must step into evaluation. Performance is always working contra-
productive and will be your enemy in planning and execution.
Before starting even the planning of the holistic migration of shared services, start testing, testing
and testing again.
I recommend a 3-phase test/ evaluation!
1. Running the migration principals in a QA or Test Tenant provided and it should be very close
to the setup of your production tenants
This is ensuring your principals work, like admin accounts, permission, and other
2. Evaluate the same approach in the live Tenant especially ensure permissions and if you are
using multiple migration tools, ensure the migration principals and sequence is work as
expected.
3. Run a PERFOMANCE/ SPEED test with the defined migration plan and setup in the live-
tenant.
This is crucial, because every tenant is different in performance (location, user count, …)
Only those results will provide you with an acceptable performance result, useful for rollout/
migration schedule plannings.
After those test and speed results, incorporate the information into your Change & Adoption plan.
This will help your teams preparing a user communication dealing with disturbing process of a
Teams CROSS-TENANT migration.

Enterprise Voice Teams Migration for Tenant to Tenant
With Team Enterprise Voice you have three choices of PSTN connectivity.
1. Direct Routing – your own SBC with a PSTN Provider
2. Operators Connect – hosted and managed SBC booked via M365
3. Calling Plan – Microsoft operates your PSTN
Each of those solutions have their own migration procedure. Option 2 and 3 is most intense in
planning. They wouldn’t allow you splitting phone number blocks into individual numbers or ranges
to be migrated. This implies you have to have a migration of users assigned to a range (block) of
numbers. Those might mostly not match the planning you have in-place for M365 Groups related/
Channels and will cause strong interference with the user services and their experiences.
If you currently have a phone service provider or carrier and already have phone numbers for your
users or services, you need to create a "port order" to transfer those phone number or blocks to to
your new carrier. It can be Microsoft for Calling Plans. When the numbers are ported over, you can
assign those phone numbers to your users and services such as audio conferencing (for conference
bridges), auto attendants, and call queues.
The time for porting towards Microsoft can take between 1-30 days. This depends on your carrier
and location/ country.
Other challenges (I might describe in a dedicated blog) are Call Queues, Auto Attendants and more
Teams Phones, Conferencing Systems and Surface Hubs.
Those hardware devices have their own management solution and you should try aligning hardware
based changes with your user migration schedule.

Calling Plan – Microsoft operates your PSTN
With Microsoft Calling Plans, Microsoft is your telephony carrier and operates the telephony for your
company/ tenant. Microsoft do not operate in all countries worldwide.
We are talking here about a Cross-Tenant migration, our focus lies on “porting” between tenant,
within the same operator, Microsoft.
Porting within Microsoft takes usually 1-7 hours. This also depends on a phone number ownership.
In CROSS-TENANT, it could be a merger with different company names. Make sure you involved
Microsoft Porting Team early and making your process transparent.
Another planning effort is based on the local country legal requirements. In certain countries,
especially if there is a ownership change involved during the CROSS-TENANT migration, You might be
forced to migrate an entire number block. Here to, please consult Microsoft Porting Team before
you plan or start your migration.
The LOAs (Letters of Authorization) can be found here:
Manage phone numbers for Calling Plan - Microsoft Teams
Managing Cross-Tenant phone number porting
Porting can be found within the Teams Admin Center and navigate to Voice/Phone number:
Click the PORT request option.

You also can navigate directly to the wizard:
Phone number porting wizard - Microsoft Teams admin center
For here follow the instruction provided:
Next Steps:
- Select your country (toll-free or geographical number)
- Add you phone number (manually or CSV based)
- Manage number (best use Excel)
- Add your account information
- Add your number features
- Complete your order
I recommend you are using an Excel sheet, so you are able to incorporate the porting date, based
on your CROSS-TENANT user migration schedule.

Country or
region
Country or
regional code
National number E.164 number
(Country code +
National
number)
PORTING DATE
Germany 49 89-1234567 +49891234567 16. Sep. 2022
Germany 49 89-1234568 +49891234568 16. Sep. 2022
US. 1 425-555-1234 +14255551234 02. Nov. 2022
Note:
List every phone number, even if they are in a number block.
If you are facing issue during porting:
If you notice any issue with the ported numbers within the first 24-48 hours after the port
completed, contact the TNS Service Desk. For any issue that goes beyond 48 hours, contact the
Microsoft Support Team.
Scheduling Cross-Tenant phone number porting
The approach for calling plan number porting required pre-work with the Microsoft Porting Team.
First said, the porting teams are distributed across countries and have local working hours.
Those working hours are:
Working hours are: 8:00 am until 5pm
It this therefore necessary unassigning the phone number form the source tenant approx. 30min
before the porting request is made. Porting can take between 2-6 hrs.
In several case, you might now able to port/ migrated all users on a single day which have a number
block assigned. This is mostly the case, if the range/ count of users excite 400-600.
Working around this requires early involvement with the local porting team. They need to prepare
and grant the exemption of partial number migration.
This needs to be discussed and Microsoft porting team to be informed at least 2 week prior to the
planned migration day/ window.

Operators Connect – hosted and managed SBC booked via M365
Literally, you can see Operators Connect as a mixture of Direct Routing and Callings plans.
The advice towards an operator connect change is, engaging your carrier/ provide very early. They
might have their own procedures. They mostly operate their own SBC infrastructure could offer a
dual forking in the same approach as described in the section Direct Routing. It also could be they
operate eSBC (Enterprise SBC).
You still need following their procedures and this can make it completely different for the User
CROSS-TENANT migration approach and schedule.
Nevertheless, there is always an option. Users can be migrated to the target tenant without
telephony. For placing and receiving calls, user can login to their source tenant handling calls for
there.
This is truly not the best user experience, but possible.
Same will apply to Call Queues and Auto Attendants.

Direct Routing – your own SBC with a PSTN Provider
Best option as usual is the Direct Routing. Where I will focus on in this blog article.
SOURCE
Tenant
PSTN
Number Block:
+49-89-1234-000/999
+1-20-4545-100/199
Client PSTN
Infrastructure
E.g. PBX, Call Center,
other service
Mediant 4500
Or any other
SBC
During migration, there might be other services using PSTN, like a PBX or even a Call Center. This is
not part of this migration consideration, but with the described migration approach, it is separated
from the Teams migration. This will provide you with more flexibility than the other PSTN interaction
possible in Teams.
In general with any PSTN provider it is difficult or even impossible splitting PSTN number block along
with your migration of users. Therefore another approach must be implemented.
Additionally the described process also eliminates the need of additional SBCs in your environment
and protects your investment.
The idea and used method is called DUAL FORKING.
Dual forking is the possibility addressing a call to multiple destinations. In our case we want this dual
forking happening between two Microsoft M365 Tenants.
How is a call established with the SIP protocol.
Phone System Direct Routing - Microsoft Teams | Microsoft Docs
We start with the generic understanding of SIP in Microsoft TEAMS.
The following illustration shows an incoming to the phone number 0049-89-1234-1000, which
should be Bob’s Team phone number. It contains a Refer, which is not relevant for the further
explanation of the migration solution.

Important is the process of INVITE, TRYING, RINGING, SESSION PROGRESS and OK, ACK. In the next
illustration if simplify the call setup. But here you see the client involved, with is explained in detail
within the MS DOC’s article.
INVITE:
sip:00498912341000@10.10.10.10:5061;
user=phone ...
The illustration in detail:
INVITE: Call is send from the SBC to the M365 SIP Proxy, where the phone number is identified for
the called user.
100 TRYING: while M365 tries calling the users Teams Client
180 RINGING: if the user was found and the call is signaled to the respective client, the phone
ringing is initiated
200 OK: The client will take the call
ACK: Taking the call is acknowledged
MEDIA: The media, talking takes place
BYE: here the caller ends the call
200 OK: The client/ M365 acknowledges the call ending

INVITE
100 Trying
180 Ringing
200 OK
ACK
MEDIA
BYE
200 OK
Call establishment
Call established
Call ended
We assume now a user has been migrated, but the phone number is present in the number block
assignment. Therefore the callee cannot be reached. Microsoft Teams well drop the call with a 404.
This SIP 404 Not Found is the message send back to the SBC and the PSTN call will be dropped.
INVITE
100 Trying
404 NOT FOUND
ACK
Call establishment
With no number
assigend
This are the two scenarios we need to understand on how SIP call establishment works.
If a user is migrated incl. his Teams PSTN number, a call send to the source tenant will be dropped
due to 404 Not Found. In our migration we still want this call to be answered by the target tenant.
This implies that we need to send an INVITE into it. We can do so with a single SBC configured for
Direct Routing.
The generic setup looks like the illustration below.

SOURCE
Tenant
TARGET
Tenant
PSTN
Client PSTN
Infrastructure
Dual Forking
Mediant 4500
Or any other
SBC
During the migration, a call is generally signaled into both, the source and the target tenant. We
want this scenario. As if a users has been migrated, it doesn’t matter where the phone number is
assigned. One of the both tenants will answer, while the tenant where the phone number isn’t
present will drop the call.
This is amazing, as we do NOT need to individually configure any phone number on the SBC.
Some requirements are necessary here:
1. Setup to INTERNET facing SIP Interfaces with different IP’s
This is a must, because Microsoft Teams SIP Proxy, cannot differentiate a call from a single IP
for different tenants.
2. Use if possible two different Certificates
(Note: SAN entries will still work, but you will later decommission the source tenant, best
keep the new certificate for the target Source Tenants it is)
If you do not follow this advice, the Dual Forking will FAIL !
In this configuration, it is absolutely required that any 404 Not Found message must be DROPPED at
the SBC.
The next illustration show’s the call drop to the user how is not assigned with a phone number in
Teams. Say Bob is migrated and has a phone number in the target Teams tenant, signaling into the
source will cause the 404 and established the call within the target tenant.
Opposite for Jane, who isn’t migrated and not present in the target tenant with a PSTN number
assigned, the target tenant will answer with a 404 and the source tenant will stablish the call.

INVITE
100 Trying
ACK
MEDIA
BYE
Call establishment
To source failed
As expected
DO NOT send 404 to
PSTN, drop instead
Call established
Call ended
SOURCE
TARGET
Phone number assigend
404 NOT FOUND
ACK
INVITE
100 Trying
180 Ringing
200 OK
Call establishment
Now you understand how simple a Teams Enterprise Voice migration from the user perspective can
be.
NOTE:
It is still required to consider Call Queues, as all users in a CQ must be migrated at the same time,
including the Call Queue. Do not try splitting the users, CQ in this case is broken.

Handling Call Queues and Auto Attendant during Cross-Tenant Migration
Note:
Call queues can’t be externally chatted with. This is an important information and is the main
problem you will have to deal with.
Nevertheless, there is a feature, where a call is assigned to a Teams Channel. This allows at least the
functionality of Guest User Access.
Steps for handling Call Queues:
1. Identify all Call Queues and Groups/ Channel(Teams)
2. Identify all User assigned to Call Queues
3. Identify Users assigned to multiple Call Queues
4. Identify the purpose of each Call Queue
5. Identify Call Queue used internal, external (phone), internal and external, channel used
For all Call Queues used internally, discuss and consider changing them to a Channel based Call
queue and build a solution for revers Guest Access. Meaning, make sure you have a process included
where migrated users, using the call queue have access via Guess Access from Target to Source.
It is advised, that users in a Call Queue (Agents) should be migrated jointly together. This is an
important task for the Rollout Managers.
Migrating Call Queues therefore might be tricky, as the purpose of the call queue is important for
the decision “when to migrated”. The main users who use the Call Queues have to be migrated to
target before you migrate the CQ.
Another approach might be, migrating Call Queues at the end of the user migration. User migrated
are still able to access their source tenant Teams for Call Queues and for Teams not migrated yet.
A special focus should always be on externally used (customer/ vendor/ partner) Call Queues and
might be scheduled for a weekend. Here if a call queues is using a MS Calling Plan, a downtime must
be planned.
Always prepare the target with the Call Queue without phone number. Users can already be
assigned to the Queue/ Group, as they are present for data pre-load in the target environment.
Summary:
There is not direct migration, it is always a new configuration. Your scheduling for preparation in the
target and the actual user (call queues group) migration is critical.

Teams Personal Chat Migration
The largest challenge I have been facing is migrating 1:1 chats from one Teams tenant to another.
1:1 Chat Migration is extremely slow. Guess you have experienced this while using Teams App. If you
scroll within a chat and reached the non-cached messages, they are pulling very slow. This is what
you will experience upon execution of Chat messages.
Additionally complex is the availability of shared files. If OneDrive isn’t fully sync’ed, placing the
sharing information is impossible. This indicates the sequence for user service migration.
Let’s list the three major challenges in personal chat migrations:
1. Counting the Private Messages
Teams has no out-of-the-box possibility counting the personal/ group chat messages. You
could write a script using the GraphAPI: getTeamsUserActivityCounts method
A limitation exists here, it can only return the number of messages in a specified period (D7,
D30, D90, and D180). It does not return the total number of private chats or messages, you
will have to extrapolate the message count for the entire exitance of the users Teams usage.
However, more accurate is getAllMessages method in the Graph API, but this call is very slow
and runs therefore for ages. Furthermore, it will run in loops and counts message multiple
times, simply said, for each user involved in a chat it counts 1 for each in a run.
Alternatively using Get-ExoMailboxFolderStatistics to view the Chat messages in a Mailbox is
possible too. It isn’t as precise because there is no way to identify and remove duplicate
messages. The count of messages may be higher than the number of messages that will be
migrated.
2. Best sequence to migrate the private chat messages
The common wish is, that during a CROSS-TENANT migration chat messages should be
present at user cut-over day. This is nearly impossible to schedule. It is slow, Notifications
might occur during adding (migrating) a chat message. Migrated chat message might also
look different, as they are posted on-behalf of a service account
Migration options and solutions I provide later in this blog text.
NOTE:
Another topic to be considered is, do not migrated chat messages before the user starts
using the target Teams. This is because there is no DELTA migration option.
If you would provision (pre-load) Teams personal Chat before you migrated the users Teams
service, all messages from the point of pre-load until cut-over are left behind !
3. GraphAPI and Tenant Throttling
Throttling is a pain in the “behind” and you ALLWAYS will hit the tenant limitations.
There is NO way avoiding throttling.

At the end of this blog, you will find the link to Microsoft Doc’s with the performance
limitation implemented into MSGraph applying to both the READ and WRITE API. All you
scripts and all vendors on the market are relying on the those limitations, regardless what
they promise.
APIs used for chat migration
There are two APIs, one from SharePoint and the other Team Graph API, whereby only the Export
API can be used to find the private chats and read the messages. The Microsoft Graph API can write
private chat message content to the target tenant
The SharePoint Migration Export (Asynchronous Metadata Read) API
https://docs.microsoft.com/en-us/sharepoint/dev/apis/export-amr-api.
• Can force multiple reads of messages depending on how many chat participants are involved
(Group Chat)
• Allows for incremental migration
• Does not support batch processing
• About the same fidelity of content as the Microsoft Graph API
• Provides faster for reading. See Microsoft Teams service limits using Teams Export API.
Teams request type Limit per app per tenant Limit per app across all tenants
GET 1:1/group chat
message
200 requests per second (RPS) 600 RPS
• Can find the private chats (and the chat ID) and read the chat messages.
The Microsoft Graph API
https://docs.microsoft.com/en-us/graph/use-the-api
• Allows for incremental migration
• Does not support batch processing
• Slower for reading. See Microsoft Teams service limits using Graph API
Teams request type Limit per app per tenant Limit per app across all
tenants
GET 1:1/group chat message 20 RPS 200 RPS
• Cannot find the private chats (or the chat ID); nor find the messages in the private chats.
Information about private chats is not available.
Writing with the Microsoft Graph API private chat message content to the target tenant limitations
and speed:
• Impersonate the original owner of the chat message when writing the messages is not
possible. As the message owner cannot be written, the MIGRATION ACCOUNT is use instead
as owner. Most tools will do so and using the “owns name” as message information.
• Microsoft Graph API’s read and write speed is identical (which cannot be used for chats and
chat messages); but it is much slower than Export API’s read speed (which is used for chats
and chat messages). See Microsoft Teams service limits using Graph API

Teams request type Limit per app per tenant Limit per app across all tenants
POST 1:1/group chat message 20 RPS 200 RPS
Another implication for users to be migrated exist and impacts the user experiences massively:
• Message notifications.
for each message created, which the write process is doing also, the Teams client
notifications sent to users cannot be suppressed via an API method when writing private
chat messages to the target tenant. This includes @mentions of users within the private chat
messages. It is a disturbing behaviour where users will receive a huge number of
notifications in Teams if he is working actively in the target environment. The receipt of
these notifications is a common complaint of users during the private chat message
migration.
The only solution so far is: asking users to disable notifications in the settings of the Teams
client in their target tenant (Figure 1).
NOTE:
Even if you decide migrating only several days/weeks/month of private chat messages, indexing/
counting ALL messages is require and slow down your migration.

Migration Options for Teams Chat Messages Destination
We take away, that is nearly impossible provisioning Teams personal chat messages on time and
along with other personal data migration during the cut-over day. Therefore left is, how or where we
can stage the personal chat messages.
Generally, the migration consist of two phases, reading and writing the message. Those both
processes are individual.
Writing chat messages into the target tenant with all listed possibilities:
1. Write the private chat messages to a folder in Outlook in the target tenant.
By doing so, there are limitation for users. Outlook folders will display the messages in the
Teams client, nor are those messages searchable or readable from the Teams client.
2. Migrate all the private chat messages from source to the target appearinf in Teams.
It is so fare the best user experience option, with the limitation, that the migration account
is the “new messages sender”. Speeding up this process, as it is extremely slow !! If possible,
merge the messages in a private chat minimizing them into a smaller number of messages.
(This increases the migration speed a little, due to faster writings, as less/ consolidated
messages are written)
3. Migrate the most recent messages only and leave older messages behind in the source
tenant. This provides a partial user experience because not all the messages are migrated.
The options commonly are D7, D30, D90, and D180
4. Migrate all messages and write the remaining messages to an HTML file.
The HTML file is stored in the Microsoft Teams Chat Files folder in the OneDrive of the user
who initiated the original private chat and direct permissions assigned to the other users in
the private chat. This solution also delivers a partial user experience, but it is better since all
messages are available to the users. Users can open the HTML file to search for and read
messages. The challenge for users is that they must search for messages in two places:
A. In Teams chat
B. in HTML files containing the archived chats
5. Write all the private chat messages to an HTML file.
Same as with topic 4., this also provides a partial user experience, but the user cannot access
their messages directly in the Teams client (unless the HTML files are added later to a private
chat.) Additionally, the user must search for messages in the HTML files containing the
archived chats.
Note: The HTML file is stored in the user’s OneDrive and direct permissions granted to the other
users in the private chat. This implies, that all users are present in the target tenant. If a user isn’t
present in the target, sharing will not work and cannot be assigned automatically later (the user
would have to do it manually afterwards)

User Experience Teams Chat Massage visualization in Target Tenant
Original Source Messages:
Migration will take place under the migration account
Messages in Target Tenant without merge:

Messages in Target Tenant with merge option:

Realistic approaches that need to be considered in the planned migration schedule
Given the project deliverables and the limitations with Chats migrations API, even with an optimised
tool configuration leaning heavily towards archiving chat messages, there are still challenges that
will limit the Chat migrations from keep up with the user migrations schedule. This leaves mostly
two realistic approaches that need to be considered in the planned migration schedule:
Align User migration batches to Chat migration throughput:
This requires reducing the planned users batches per day to a number that is attainable with
the Chats migration throughput. This offers the best user experience as users can be
migrated with access to last X days live chats (recommend 15 days and not more than 20
user per migration batch), with the remaining chats archived. In this situation we would be
making the Chats migration the key driver for the migration pace, hence an extended
migration window due to slow throughput. It is worth noting that the need to achieve a “no
data loss” (all chat messages being migrated) outcome would result in an heavily extended
migration window.
Decouple Chats migration from the User migration:
While this has a direct impact on overall user experience, it still holds up the “no data loss”
(all chat messages being migrated) requirement, mitigates administrative challenges with
alignment of chats migrations to user migration batches, and crucially does not derail the
planned user migration schedule.
There are, however, some caveats to this approach:
1. Extended migration window - this is presently inevitable if the ‘no data loss’
requirement is to be accomplished; however, this would mean running the chats
migration at the end of the user migration project
2. User experience impact on cut-over day (starting with an empty Teams in the target
tenant), messages will “fly” in or HTML files provided at a later stage in time.
Nevertheless, it is nearly unpredictable how long a personal chat migration will take. This is
independent from the storage location you will chose.
Throttling Consideration:
When you exceed a throttling limit, you receive the HTTP status code 429 Too many requests and
your request fail. The response includes a Retry-After header value, which specifies the number of
seconds your application should wait (or sleep) before sending the next request.
https://docs.microsoft.com/en-us/graph/throttling-limits#microsoft-teams-service-limits

Teams/SharePoint/OneDrive throttling examples:
"Resource is temporarily unavailable. Retrying in 3 minutes."
"Error occurred while executing the request. 429 (Too Many Requests) {
"statusCode": 429, "message": "Rate limit is exceeded. Try again in x
seconds."
"Error occurred while executing the request. 503 (“Server Too Busy”) {
"statusCode": 503, "message":
"Rate limit is exceeded. Try again in x seconds."
NOTE: It is not currently possible to request an increased SharePoint throttling policy from
Microsoft. The only option is to run the workload during "off hours" for the Office 365 tenant region,
when SharePoint throttling policies are automatically increased by Microsoft.

Personal Chat Migration into Azure Data Lake
Another approach, rudimentary described in the white paper is, migration or better said exporting
Teams chat messages into Azure Data Lake solution.
To be said upfront, this is not a solution you or a consultancy company can do, rather you must
engage Microsoft (MCS/PSS). This is an internal Microsoft solution using a private API for export.
There are several options on how data can be extracted:
- Single large XML file
- Individual XML files per Teams user
There is no other way yet, rather than using XML. Further, you must purchase an Azure VM and
Azure Storage. The costs aren’t too high and acceptable.
After Chat message extraction, the consolidated XML file will be sent via email or copied into
OneDrive.
Talking about user experience. This is not a user-friendly option! As user must have an XML reader
and message can only be found by an XML search. This makes it difficult finding messages.
But in case of compliance or other relevant requirement, where chat messages must be taken along
during a cross-tenant migration, this option should be considered.

Teams Channel Migration
Starting with the generics of Teams Team/ Channel migrations. There can be not Team without a
corresponding M365 group. This implies, that other services are available, and Teams is heavily
depending on those. Mainly it is SPO/ OneDrive. It is used for files in Teams.
Not talking about the M365 Group provisioning here in detail, but the important sequence you must
follow is:
1. Create a user mapping file and provision target users
2. Provision M365 groups in target tenant
all member user must exist
Note for M365 Groups:
There is no tool available yet, which could keep M365 Groups in persistent sync. Therefore, delta
sync’s are required.
Other services used by or from within Teams are e.g. Tabs, Wiki & Planner. Shared Mailbox are not
part of the Teams integration, but other apps made available in Teams might.
M365 GROUP associated Services
SOURCE
Tenant
TARGET
Tenant
SharePoint Site
created links/ shared items
Teams SharePoint Site
(Wiki, Tabs, Planner)
Teams Initialization
(Teams, SP Hull, )
Exchange Shared Mailbox
Exchange M365 Group Mailbox
Teams Voice (PSTN) and SBC
related Tasks (manual and scripted)
M365 Groups
Secondly, Teams has shared channels and private channels. Both have their own complexity.
• Private channel require a Teams “hull” provisioning and cannot be delta provisioned.
• Shared Channels required a user mapping source to target for Guest User
Guest User must be provisioned before the provisioning and migration starts
(Note: at the point of writing this article, shared channels are in public preview)

Let’s talk about a “hull” provisioning. After M365 Groups are copied, the process of provisioning
services starts. A Teams hull, consist of the readiness of SharePoint Online, OneDrive and Site,
further the entire Channels in Teams. This is the structure only, without any content.
It is advised before doing any content migration, ensure the especially for PRIVAT and SHARED
Channels, the structure “hull” is re-provisioned/ copied again.
Than a FREEZE must be applied, because any changes to the private channel (memberships) will not
be reflected.
It is not required using a single migration tool for this holistic process, rather it could be segregated
into different tools. Only for the provisioning incl. the involved users, it is recommended doing it
with the same tool.
You can even use different tool for say, SharePoint sites and OneDrive. You have to evaluate the
content making the right decision with set of tool will support you best and which method you could
apply for those service and reuse them from other migration tasks.
The other important topic is, that OneDrive must be provisioned and migrated before you can
migrate chats into the channel. Messages might contain documents shared, those files you will find
in ODB. Applying the shared permissions again, and further LINKING the file to the chat message
require those to be present in the target already.
Sequence for Teams Team migration (Team/ Channel)
1. Provision users and guest users in target
2. Have user mapping file ready and complete
3. Provision the M365 Groups in target
4. Synchronize the Teams “HULL”/ structure incl. private/ shared channels
(Teams provisioning)
5. Start content migration for OneDrive, SharePoint and Mailbox (pre-load)
6. REPEAT: Provision the M365 Groups in target
7. REPEAT: Synchronize the Teams “HULL”/ structure incl. private/ shared channels
(Teams provisioning)
8. Freeze source Teams Team and services assigned along
9. Initiate final migration of all service (at least ODB, SPO)
10. Start Chat Migration / Channel

Personal Data migration Exchange and OneDrive
In the previous chapters, it is stated: Teams make use of several M365 service. Especially for the
personal side of Teams, Exchange and OneDrive are heavily involved.
Towards Teams migration, it is required, that ALL data is present in the target environment for
Exchange Calendar and OneDrive (shared files).
Data Pre-Load
Data pre-load is much slow than you expected. This is the most important lesson learned.
While Exchange is faster than OneDrive, be aware of the time required for the data copying process.
Another important statement is: none of the existing solutions are SYNC solutions, data is only
copied. Therefore, a co-existence and working parallel in both, source and target tenant can lead to
data inconsistence. If data is changed in the target environment and in source, any delta sync will
overwrite the target data, if source has a new change date. Same, if the target data is newer,
changed source data will not be copied.
Throttling
All service in M365 are throttled !
Throttling limits are different across the tenants, smaller tenants have low limits than larger tenants.
For Exchange, throttling can be lifted upon certain stage. This must be requested via the support
center in M365. But it is NOT removed.
For OneDrive, this is even more complex and throttling will occur. There is NO possibility lifting or
removing throttling. Up on throttling limits are hit, the only possibility is WAITING and reducing the
read/write request.
OneDrive, which is part of SharePoint Online has the following rough guidelines:
Avoid getting throttled or blocked in SharePoint Online | Microsoft Docs
The following table provides estimates of the type of speed you may achieve based on the types of
content you're migrating.
Type of metadata Examples Maximum
Light ISO files, video files 10 TB/day
Medium List items, Office files (~1.5 MB) 1 TB/day
Heavy List items with custom columns, small files (~50 kb) 250 GB /day
• Large file size migrates faster than smaller ones. Small file size can result in larger overhead
and processing time which directly impacts the performance.
• Files migrate faster than objects and list items.

Lets do a quick and simple calculation. Assuming a tenant has 10.000 users and 500TB or SharePoint/
OneDrive data.
It can simply take up to 500 days or more migrating all data into the new target tenant!
Conclusion
Plan enough time for data migration. Test the speed between the production tenants. Be aware,
that the migration slows down over time. If you are close to completion, the migration speed will be
slower than the former average.
Speeding up the migration can only be archived by the following 2+1 solutions:
1. Clean-up your environment. Delete and data not in use, or not required.
2. Limit the amount of data required, e.g. do not copy version history, only data to certain date
3. Use archiving/ backup solutions and store data anywhere else, e.g. Azure or on-premises.
Limiting the amount of data required to be copied.
There may be new tools in the future and it might get better and faster.
Co-existence DNS Domain issue
In the Cross-Tenant migration, both tenant will have a co-existence phase. In each tenant DNS
Names are registered and used for external service communication. This is from UPN login, Email
(SMTP) and Teams SIP calls. A DNS name cannot be registered into two tenants at the same time.
The Authority record will not allow this with M365.
There are solutions, providing better user experience, but some service do not allow you working
with both DNS names. Realtime solution, like Teams and data protection solution have no work-a-
rounds.
For CROSS-TENANT migration you have two choices, either you apply the target DNS to all migrated
users and service, while retire the source DNS domain. Second option is, migrating the source DNS
domain into the target tenant during source tenant decommissioning.
1. SMTP/ Email
Make use of an external cloud based SMTP redirect solution. This will allow an redirect of
mail flow from source to target, keeping externally the same DNS domain in your emails
send and received.
2. Teams SIP/ Chat and Calls, Meetings
There is NOT possibility redirect or masking SIP flow with two DNS domains. Therefore,
during user migration, a user migrated to the target tenant cannot have the source DNS SIP
domain. You must use the existing DNS domain, or a temporary DNS domain.

3. Data Protection (MIP/AIP)
MIP depends on an encryption key created in the source tenant, which is build based on the
source DNS name. Therefore authentication/ de-/encryption is based on this.
Migrated content, not decrypted will only be accessible as long the source key exists.
Therefore I suggest either migrating the key while you move the source DNS domain to the
target tenant.
If the target DNS domain shall be used instead, you must de-crypt the data before copying
and re-encrypt the data with the new MIP key in the target.
Another challenge are the shared services, like Teams Team/Channel or SPO and M365 groups
service, as well as other service like Yammer, … There is no simple solution, providing access to a
migrated user from target to source. Two possible solution you can think of:
1. Keeping the user account in source active, while disabling the personal services if the user is
migrated. The user must work in both tenants. This is complex situation for most of the
users.
2. Make us of Guest Access and provide for each user who is migrated a corresponding guest
user access in the source tenant. This is at least a solution he could life with. But for the
migration team, this is extremely complex and work intense.
The only way making a CROSS-TENANT less painful for users, is a proper Change & Adoptions
approach. Key users, Champions and more would make a CROSS-TENANT migration more successful.

Cross-tenant Shared DNS Space
(Native Cross-Tenant Domain Sharing for Exchange Online)
Upcoming new features, describe and change migration approach:
Reference: Supporting Mergers, Acquisitions, and Divestitures in Microsoft 365 - Microsoft
Community Hub
Microsoft has announced publicly a new expected solution architecture and some of the
configuration and management tasks you must perform when utilizing native cross-tenant domain
sharing functionality.
Below, the step-by-step description to enable cross-tenant domain sharing for a single SMTP
domain. (valid as long no major changes are introduced by MS)
The domain will be Authoritative in the Tenant where you perform the primary domain
management. Up on enablement for domain for cross-tenant domain sharing, you will be able to
add the domain as an Internal Relay in additional tenants. An internal Relays is like in Exchange On-
Premises relay configuration.
Cross-Tenant Domain Sharing Configuration
Enabling domain sharing for source-tenant.com in Source Tenant so that source-
tenant.com can be assigned as a Primary SMTP address to the mailboxes in Target Tenant.
1. Add source-tenant.com as an Accepted Domain in Source Target before adding it to other
tenants
• Domain appears as Type: Authoritative
2. Configure source-tenant.com in Source Tenant to allow sharing with Target Tenant
• Microsoft will provide full details for this task once the feature is public
3. Add source-tenant.com as an Accepted Domain in Target Tenant
• Domain appears as Type: Internal Relay
4. Configure Inbound Connectors that are in each tenant to trust the opposite tenant
• Source Tenant connector configuration:
SenderDomains={smtp:source-tenant.com;1}
TrustedOrganizations={smtp:target-tenant.onmicrosoft.com;1}
• Target Tenant connector configuration:
SenderDomains={smtp:source-tenant.com;1}
TrustedOrganizations={smtp:source-tenant.onmicrosoft.com;1}
5. MX Record for source-tenant.com points to Source Tenant
• Inbound messages for all source-tenant.com addresses will deliver to Source
Tenant and then routed to Target Tenant

Primary SMTP Address Assignment
With the cross-tenant domain sharing architecture in place, you can now start to assign
source-tenant.com email addresses to mailboxes in Target Tenant, which has target-
tenant.com as an Authoritative Accepted Domain.
1. Create a mailbox in Target Tenant, which will have a UPN for a domain that is owned by
Target Tenant
• Example: userA@target-tenant.com
2. Set the Primary SMTP on the mailbox in Target Tenant to a unique source-tenant.com
address
• Example: userA@source-tenant.com
• Microsoft will provide full details for this task once the feature is public
The user is now able to send emails from his mailbox in Target Tenant as userA@source-
tenant.com even though that domain is managed by Source Tenant.

Cross-tenant Identity Mapping (preview) approach:
Cross-tenant mailbox migration - Microsoft 365 Enterprise
Cross-Tenant Identity Mapping is a feature that can be used during migrations from one Microsoft
365 organization to another (commonly referred to as a cross-tenant or tenant-2-tenant migration).
It provides a secure method of establishing one-to-one object relationships across organization
boundaries and automatically prepares the target objects for a successful migration.
With Cross-Tenant Identity Mapping, data remains within the Microsoft security boundary and is
securely copied directly from the source organization to the target organization using specially
configured Organization Relationships serving as a unidirectional trust.
This blog article is still designed for 3rd
party tool usage and might be updated at a later stage.

Cross-tenant Mailbox migration approach:
Cross-tenant mailbox migration - Microsoft 365 Enterprise
Users migrating must be present in the target tenant Exchange Online system as MailUsers, marked
with specific attributes to enable the cross-tenant moves. The system will fail moves for users that
aren't properly set up in the target tenant.
When the moves are complete, the source user mailbox is converted to a MailUser and the
targetAddress (shown as ExternalEmailAddress in Exchange) is stamped with the routing address to
the destination tenant. This process leaves the legacy MailUser in the source Source Tenantnd allows
for coexistence and mail routing. When business processes allow, the source tenant may remove the
source MailUser or convert them to a mail contact.
Cross-tenant Exchange mailbox migrations are supported for tenants in hybrid or cloud only, or any
combination of the two.
Cross Tenant User Data Migration is available as an add-on to the following Microsoft 365
subscription plans for Enterprise Agreement customers. User licenses are per migration (onetime
fee). Please contact your Microsoft account team for details.
Microsoft 365 Business Basic/Business Standard/Business Premium/F1/F3/E3/A3/E5/A5; Office 365
F3/E1/A1/E3/A3/E5/A5; Exchange Online; SharePoint Online; OneDrive for Business.
This blog article is still designed for 3rd
party tool usage and might be updated at a later stage.
Using the Microsoft Cross-Tenant Migration for Exchange you have to consider the following:
• Do update RemoteMailboxes in source on-premises after the move!
You should update the targetAddress (RemoteRoutingAddress/ExternalEmailAddress) of the source
on-premises users when the source tenant mailbox moves to target tenant. While mail routing can
follow the referrals across multiple mail users with different targetAddresses, Free/Busy lookups for
mail users MUST target the location of the mailbox user. Free/Busy lookups will not chase multiple
redirects.

Free & Busy Sync during Cross-Tenant Migration
You have two options “migrating” mailboxes cross-tenant:
- Microsoft Cross-Tenant Migration
this will move, reconnect a user’s mailbox in target and removes the source mailbox entirely
- Using a 3rd
party tool, copying the mailbox content and syncing calendars
this will leave the source mailbox intact and can confuse users in the source environment, which
user is now active (see the user adoption story)
Organization relationship in Exchange Online
If you migrate the User Mailbox entirely, meaning, nothing is left behind in the source, you can use
Organizational Free/Busy Lookup:
This feature is named: Organization relationship in Exchange Online
This allows:
- Set up an organization relationship to share calendar information with an external business
partner.
- Set up an organization relationship with another Microsoft 365 or Office 365 organization or
with an Exchange on-premises organization.
But is not a free/busy synchronization, rather this is a normal EWS based calendar share and query
feature. Users which are migrated, do not have a mailbox in the source tenant and there for a
free/busy query against the target, with the new target email address can be initiated
There are three levels of access that you can specify:
• No access.
• Access to availability (free/busy) time only.
• Access to free/busy, including time, subject, and location.
Follow this Microsoft article for setup:
Create an organization relationship in Exchange Online
NOTE:
It can be used while source mailbox are intact, but there must be a solution, e.g. Out of Office
notification, stating other that a user has been migrated and is working actively on the target side !

Free/Busy sync cross-tenant with Exchange Online
If you have used the copying mailbox content and permission option, e.g. with 3rd
party tool. Mostly
the source mailbox will stay as is. It might be required for accessing Share or Group mailboxes during
the migration. If this is the case users still active in the source tenant need to know if a user is active
where (source or target) if you use the Organization Relationship.
Another technology option comes into place, Calendar + Free/Busy Sync! It is always a 3rd
party
solution.
Free/Busy sync is established between the source and target tenant. Keeping users calendar in-sync.
This applies to both possible directions from source to target and from target to source. If a calendar
is in sync.
Free/Busy is part of a EWS calendar sharing feature and can be enabled e.g. in Quest on Demand
cloud migration suite.
Calendar Sharing Create a relationship between the source and the target tenants to allow users to
retrieve calendar availability information:
1. Log in to Quest On Demand and choose an organization if you have multiple organizations.
2. From the navigation pane, click Migration to open the My Projects list.
3. Create a new project or open an existing project.
4. Click the Accounts tile, or click Open from the Accounts tile to open the Accounts and User
Data dashboard.
5. Click Enable Calendar Sharing and verify the source and target domain names. Click Next to
proceed.
6. Schedule when the task will be started. Click Next to view the task summary
7. Name the task and check the selected options.
Click Finish to save or start the task depending on schedule option selected.

Cross-tenant OneDrive migration approach:
Cross-tenant OneDrive migration overview - Microsoft 365 Enterprise
During mergers or divestitures, you commonly need the ability to move users OneDrive accounts
into a new Microsoft 365 tenant. With Cross-tenant OneDrive migration, Source Tenantdministrators
can use familiar tools like SharePoint Online PowerShell to transition users into their new
organization.
SharePoint administrators of two separate tenants can use the Set-
SPOCrossTenantRelationship cmdlet to establish an organization relationship, and the Start-
SPOCrossTenantUserContentMove command to begin cross-tenant OneDrive moves.
Important Note:
Some special characters in users names aren’t supported with ODB cross-tenant migration. This are:
“_”, ….
Ensure the cross-tenant license has been assigned to a user before cross-tenant migration.

Example of our user data migration approach:
Important is the completion of your data pre-load for OneDrive and Exchange.
Remember, that the pre-load should include as much data as possible. Syncing on the cut-over day
data > 10 GB or more than 500 files in OneDrive, might end up with an INCOMPLETE set of data in
the target. Therefore, you should urge using the OneDrive Cross-tenant OneDrive Migration tool
from Microsoft.
The user will than see data being migrated (missing data) upon he starts working in the target
environment. This will not be happening with the cross-tenant migration tool. The switch to the
target tenant will take approx. 15min.
Migration of Teams personal Chat messages, we mostly limit to 15 days. The performance is
acceptable migrating approx. 400 – 800 users/day.
Note:
You should have special procedures in place for legal-hold users, white glove and user object facing
issues.
1. Prepare source and target Source Tenantnd ensure the readiness for Microsoft tools
2. Prepare computer migration (if it goes along with the user migration) and start the computer
migration (3rd
party tool)
3. Teams EV Phone Number assignment
4. Place user in any AD Group required (e.g. for computer object migration/ Desktop update
Agents)
5. Set SMTP Redirect
6. Initiate OneDrive cross-tenant move
7. Migrate D15 Teams personal Chat Messages (15 days of chat)
8. Finalize Mailbox Content migration (cross-tenant move)
9. Start Teams Meeting Link Migration (3rd
party tool)
10. Run User Profile migration
11. Execute computer management (e.g. Intune, AutoPilot or SCCM)
Upon all users are migrated, you can start the Teams Personal Chat Migration, e.g. into a HTML File,
or other archive solution.

Meeting Link Migration for Teams
Note: both, first user Mailbox/Calendar and Teams must be migrated
A 3rd
party tool is required to accomplish a meeting link migration.
With Exchange Mailbox migration, all items, including calendar item will be migrated as they are.
Calendar item with a link to a Microsoft Team meeting link back to the original Team meeting in the
source tenant. The URL is retained.
A Teams Channel meeting is not recreated in the target tenant. Those meetings must be
rescheduled manually by the channel owner.
How it works (e.g. Quest): The meeting link migration task will create a new Team meeting with the
original meeting details in the target tenant. It will set the target user as the organizer. The original
meeting migrated to the target will be canceled. The cancellation will be automatically sent out to
the organizer and recipients.
VARIAN
Tenant
SHS
Tenant
1.) enable Teams user (license)
Meeting URL
Re-Write
Meeting Link Migration Considerations
Before migrating Teams meetings and their respective link, be aware of the limitations from the
tools chosen. Additionally, attendees outside your organization also receive cancelations and re-
invites. This results in questions/ confusions, if those attendees aren’t informed before the migration
occurs.
• The attendee list is not updated to match the target domain.
• A new meeting is only created if the migrating user is the organizer of that particular
Team meeting.
• Most 3rd
party tools recreate present and future meetings, both one-time and
recurring meetings. Meetings that happened in the past are migrated with Calendar
migration.
• Meetings recreated on target could result in meeting time zone updates to UTC. This is
one of the limitations of the Microsoft Graph API.
• The subsequent runs of the Meeting Link Migration Task will skip the meetings which
were previously processed.
• Properties like a flag and categories are not supported with this migration.

Note:
The cancellation email will be sent to the mailboxes of target attendees. If mail forwarding from the
target to the source is not configured for them, the attendees in the source tenant will not receive
the cancellation email. As a result, they will observe both the original meeting, which was cancelled,
and the new one, created by the On Demand service.
Mailbox migration with the Migrate Calendar option selected, must be completed before starting
this task.

Handling Cross-Tenant Guest User Access
In any Tenant 2 Tenant migration there will be cross-tenant guest user access, as well as external
guest users from partner, vendors or customers:
• Source Accounts as Guests in Target Tenant
• Target Accounts as Guest in Source Tenant
• External Guest Account in Source Tenant
This process is complex and has several approaches technically and user experience/ adoption.
A dedicated White paper will be released soon. Als reflecting revers access into the source tenant for
migrated users.

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 things 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 CROSS-TENANT 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 1st
and in target on April 2nd
, a delta migration would NOT overwrite the target
documents. Opposite, if a source document is changed on April 2nd
and the target was change on
April 1st
, 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 CROSS-TENANT 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:
Access via
Desktop apps
Access via
web apps
Migrated user
Primary account
Users within the
communication cluster can
make use of in target
tenant services.
Users outside the
communication cluster can
make use of in target
tenant services. Migrated
users can only access
service via the old source
account.
Cross tenant
communication is complex
and could only be archived
via:
Guess Access or using both
account (except for users
no yet migrated)
External User
(Guest access or
shared/ Teams)
must know both
source and target
tenant

Segregated suer/ service Migration:
Access via
Desktop apps
Access via
web apps
Migrated user
Primary account
Users can access their
personal data and existing
target data only !
Users must be restricted
using their personal data
services (OneDrive,
Exchange,..)
They can use the old
source account accessing
shared data
Cross tenant
communication isn t
necessary, as the primary
accounts are in the target
environment.
External User
(Guest access or
shared/ Teams)
must know both
tenants for
shared/ Guest
access and user
related service
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.

Cross Tenant User Adoption Process
Change & Adoption is the most critical task in any tenant-2-tenant migration.
Not only users who are migrated are impacted heavily by the migration. Users in the target tenant
too. Especially in the target tenant they will experience constant changes. New users and groups are
appearing, but not “life”, not actively working in the tenant. Further, new services related content
will sequentially appear, like SPO sites, Teams Channel, Yammer or others. Since data is flying in
slowly, there must be a communication and identification in place, that user are enabled identifying
data source in migration.
Same applies, for user in the source environment. Content/ data migrated will be in read-only.
Content could become unavailable due to accomplished migration to the target. All depends on the
migration process, procedures and planning. This needs to be communicated to all users in proper
manner.
Talking about external users, there is even a more severe impact. External users, could Guest User,
but also your customer and vendors, partners you are working with. DNS names are changing and
their buddies might disappear over time.
Clearly have a plan in place how the companies (source and target) and the users will inform outside
counterpart. By a clear communication plan, you can minimize the impact on collaboration and your
business.
Another important topic is the user life-cycle process.
Question asked is; From when onwards do you create new users in the target, rather in the source
environment? There is not a clear answer. It highly depends on the creation process and the length/
duration of the entire migration project.
A best practice would be approx. at 50% of the accomplished user migration. Starting with new users
directly in the source tenant. But again, for those certain access to source users and data will be
restricted.
After understanding partially the impact for users during a CROSS-TENANT migration, Change &
Adoption is the most important workstream in a project.
Success or Failure depends on Change & Adoption.
Important Advise:
Do not decide or make any technical approaches without the Change & Adoption team.
Not only User Experience might get bad, but the business financials, customer experience and supply
chain could be so heavily impacted, making your migration a financial disaster.
I list you some assorted issues impacting the UX and communication, even outside of your tenant:
• Teams Notification while chat migration:
If you migrate Chat messages, notification will appear for each message migrated. Only the
user himself can suppress the notification in Teams via the Teams settings.

• Meeting Link Migration:
A lot mails with cancelation and new invites being send, also to external attendees. Prepare
a proper communication.
• Teams chat message extremely slow
Migrating Teams Chat is slow, for both personal and channel chat. Plan proper, archive
where ever possible. Inform users about limited availability of chat data in their new target
environment.
• Chat message storage location and how to use
If you archive or write chat message e.g. into HTML or Outlook folder, explain the user
where to find and how to use the archive.
• Delegates
You find delegates in Teams and Exchange. Identify those and migrate the jointly together.
Inform them about the new environment and their teamed new work.
• Call Queues (CQ & AA) and the associated group of users
CQ’s are not associated to the dedicated AAD group, rather than a collection of users in
Teams Admin Center. It is advised migrating those user jointly together and setup the CQ in
target. On the other hand you need to consider how migrated user are able calling into a CQ
upon their migration, same for external access (PSTN). Plan according your users need and
functionality of the CQ.
• Migration of SPO
SharePoint only need to be set to read only during and after their final migration in source.
Regardless, you need to inform user about the status of those service, using notification and
banners. SPO will appear during migration in the target, but shouldn’t been used. Make sure
you communicate this proper to your source and target users.
• DNS Domain co-existence
DNS Domains can only be migrated at the end of your migration. You need to release the
DNS from source and re-register in the target tenant.
Be absolutely aware, that especially for TEAMS, target users can only make use of the
“newly/ old” DNS domain upon re-registration. Therefore, the SIP address on all Teams and
SMPT service can only be changed afterwards.
This all will result in another communication, that Teams users will once again contact their
counterpart/ chat buddies of the additional DNS/ user@dns SIP change. It is a disturbing
event with must be planned very carefully.

Some words to add:
A cross-tenant migration will
take much longer
than you expect.

Microsoft M365 Cross Tenant Migration Book

More Related Content

What's hot

Similar to Microsoft M365 Cross Tenant Migration Book

More from Thomas Poett

Recently uploaded

Microsoft M365 Cross Tenant Migration Book