Cross Tenant Migration Microsoft Teams

© Thomas Poett Microsoft MVP, 2023
GUIDE TO
MICROSOFT TEAMS
CROSS-TENANT
MIGRATION
(TENANT-2-TENANT)
Version 1.0 (Feb 2023)
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

Contents
GUIDE TO MICROSOFT CROSS-TENANT MIGRATION (TENANT-2-TENANT) ...................................................1
Cross-Tenant Migration Consideration and Planning Guide ..................................................................3
Cross-Tenant Teams Migration...............................................................................................................9
Summary and approach for a Teams Cross-Tenant Migration.........................................................12
Enterprise Voice Teams Migration for Tenant to Tenant .....................................................................14
Calling Plan – Microsoft operates your PSTN ...................................................................................15
Managing Cross-Tenant phone number porting ..........................................................................15
Scheduling Cross-Tenant phone number porting........................................................................17
Operators Connect – hosted and managed SBC booked via M365..................................................18
Direct Routing – your own SBC with a PSTN Provider ......................................................................19
Handling Call Queues and Auto Attendant during Cross-Tenant Migration ....................................24
Teams Personal Chat Migration............................................................................................................25
APIs used for chat migration.............................................................................................................26
Migration Options for Teams Chat Messages Destination...............................................................28
User Experience Teams Chat Massage visualization in Target Tenant.............................................29
Realistic approaches that need to be considered in the planned migration schedule ................31
Personal Chat Migration into Azure Data Lake.................................................................................33
Another approach, rudimentary described in the white paper is, migration or better said
exporting Teams chat messages into Azure Data Lake solution...................................................33
Teams Channel Migration.....................................................................................................................34
Meeting Link Migration for Teams........................................................................................................36
Meeting Link Migration Considerations........................................................................................36

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 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.

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

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.

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

Cross Tenant Migration Microsoft Teams

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Cross Tenant Migration Microsoft Teams

Similar to Cross Tenant Migration Microsoft Teams (20)

More from Thomas Poett

More from Thomas Poett (15)

Recently uploaded

Recently uploaded (20)

Cross Tenant Migration Microsoft Teams