Teams Cross Tenant 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 T2T 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.
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
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.
The process for possible Resource accounts, as illustrated below, follows the same process as it designed for users.
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.
During pre-load of channel data and services, the channel is visible and could be seen and used by users already
- You cannot hide a channel
- Private channel need to be provided before migration
- Delta syncs aren’t possible for private channel and chat messages
- Soon a channel is migrated you should delete or archive
- Cross tenant access to channels is difficult to manage if not all members with access are migrated.
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.
- 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
- 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
This is ensuring your principals work, like admin accounts, permission, and other
- This is ensuring your principals work, like admin accounts, permission, and other
- 2. Evaluate the same approach in the live-tenant and 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.
- 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 T2T migration.