Cross Tenant Migration Options for Teams Chat Messages Destination

 

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:
1. In Teams chat
2. 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 fails. 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.