Microsoft Teams is making a huge impact in Australia and the uptake of this workload on Office 365 has been incredible. Microsoft’s approach to rolling out new functionality is incremental. As a result, some of the functionality underpinning the Teams’ offering was initially hosted in a limited number of data centres. Early adopters now find themselves in the position of having parts of their data within Australia (underpinning Teams is SharePoint Online, OneDrive for Business and Exchange Online) and parts within one of the APAC data centres. This may not be a big deal for some, but if data sovereignty is a requirement for your organisation or your client, you might find yourself in a troublesome situation.
Microsoft Teams works with other Office 365 workloads to deliver its full functionality. These are:
- SharePoint Online (for team files)
- OneDrive for Business (for chat files)
- Exchange Online(for Group mailboxes)
For all Australian Office 365 tenants, content for SharePoint Online, OneDrive for Business and Exchange Online is currently being stored in Australian Data Centres based in New South Wales and Victoria. However, the Microsoft Teams chat service which handles and stores individual teams’ structure and all conversations data, uses one of the APAC data centres as its storage. This has changed for all new Office 365 tenants from August 27, 2018 as we now have an Australian Data Centre for the Microsoft Teams chat service.
Unfortunately for all existing Australian tenants who are already using Microsoft Teams, their data will continue to reside in the old APAC data centres for now. Naturally, existing Australian tenants would want to move their Microsoft Teams data locally, especially if data sovereignty is important . This is something that Microsoft is currently working on and the Teams data centre move service will be available in 2019. Until then, existing Australian tenants are stuck in the following state:
- Microsoft Teams → Hong Kong, Singapore, South Korea
- SharePoint Online → Australia
- OneDrive for Business → Australia
- Exchange Online → Australia
So, how do we move the data now?
Since there is no data centre move for Microsoft Teams available from Microsoft at the time of writing, the only other option is to set up a brand-new Australian tenant and migrate the content across to the new tenant. This decision is not be taken lightly: in most cases its quite feasible just to wait for data centre move to be available in 2019. There are two key reasons for this:
- Setting up a new tenant and moving Microsoft Teams data essentially means all other related Office 365 workloads (e.g. SharePoint Online, OneDrive for Business, Exchange Online) must be moved as well.
- There isn’t a straightforward migration API or service available from Microsoft nor is there a third-party migration tool to do the job.
Given the situation, an organisation that needs to migrate Microsoft Teams now must come up with a customised solution for their own requirements and must migrate other related Office 365 workloads as well. So, what does the migration story look like now? Note that below is an oversimplification of related Office 365 workloads as there may be many other services in use like Microsoft Planner, etc.
|Office 365 workload||Migration path|
|SharePoint Online||Both first- and third-party tools available for migration|
|OneDrive for Business||Both first- and third-party tools available for migration|
|Exchange Online||Third party tools available for migration|
|Microsoft Teams||No first- or third-party tool available for migration. Develop a custom migration process.|
Microsoft Teams – FiveP’s recommended migration approach
When planning to migrate Microsoft Teams instance between tenants, we would need to breakdown and individually consider the migration path of various Office 365 workloads and Microsoft Teams functionality. Although not encouraged, the complex path of migrating Microsoft Teams data can be somewhat achieved using the following high-level approach:
|Provision new tenant||Manual steps|
|Migrate users and configuration settings||Manual steps, third party tools|
|Migrate Microsoft Teams Structure (Teams, Members, Channels, Settings)||Custom code
(Microsoft Graph API)
|Channel conversations||Custom code
(Microsoft Graph API)
|One to one/many chats||No migration path|
|Group Mailboxes||Exchange migration using third party tools|
|Files and OneDrive for Business||SharePoint migration using first- or third-party tools|
Limitations of this approach and the options we have
Teams content stored in the workloads pre-dating Microsoft Teams (like Group Mailboxes and Files) have well understood migration approaches. The newer content can be problematic.
The general structure of the teams in your source tenant can be replicated in the new tenant using custom code or scripts that leverage the Microsoft Graph API (see https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/teams_api_overview).
You will be able to re-create Teams, Channels, Members and Settings using this approach that will provide the skeleton of your teams within the new tenant.
Microsoft Teams’ channel conversations are the core data which is stored outside of Australian data centres for existing tenants. This is the key reason most organisations would opt to migrate to a new Australian tenant, and unfortunately is the most challenging part of the migration process as well. If an organisation wants to store their new conversations in Australia and does not care about the previous ones, it’s straightforward to just skip through this, but if previous conversations are to be preserved in context, then it’s a relatively complex scenario.
Option 1: If conversations are to be preserved merely for compliance
This option is suitable for organisations only wanting to store their new conversation data in Australia. If previous conversations are needed just for compliance purposes, they are available in security and compliance centre from Office 365 admin centre. Administrators can search previous conversations on demand. Note that if Exchange migration is performed, it would need to be tested whether the conversation history makes it to the new tenant.
Option 2: If conversations are to be preserved within their Teams’ context
Microsoft Graph API (Beta) is available to list all the conversations for a channel as well as creating a chat conversation. The API is currently quite basic as you may have to retrieve message hierarchies using a complex programming scheme (see https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/channel_post_chatthreads).
Using the API, conversations can be retrieved from the source tenant and re-created in the destination tenant. There is a major limitation associated with it though. Creation and last modification dates and times from the source conversations will not be preserved at the destination. It may be worth considering migrating the conversation content to a different format (say as a document or page within the team) to avoid messy conversation history and confusion.
One-to-many chats are between individuals (not in the context of a team’s channel). Currently, there is no available API from Microsoft to retrieve and/or create chat messages outside of a team’s channel. Therefore, chat messages can’t be migrated.
Tab content is not stored within the context of Microsoft Teams, as a tab is just a pin and points to something else. The configuration of these tabs though is stored in Teams. The clone method available in the Graph API requires the source Team to be in the same tenant as the destination Team, so it is not a viable option to programmatically configure them. Unfortunately, the only current approach is to recreate the tabs manually at the destination. Similarly, if any connectors are in use within the context of a team, they will have to be manually configured again at the destination.
In summary, the migration experience for Microsoft Teams is difficult, involving low fidelity replication and piece-meal solutions. If your organisation or client can wait until 2019 for the Microsoft solution for data centre move, then you are probably best to retain your current tenant. If you are in a situation where the tenant is not established, and usage is low, you may be able to use some of these recommendations and migrate your tenant now.
I hope this helps and please do not hesitate to reach out or leave a comment below should you need assistance.