Teams Cross Tenant Migration

-

 

Teams Migration for Tenant to Tenant

 

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

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

  1. You cannot hide a channel
  2. Private channel need to be provided before migration
  3. Delta syncs aren’t possible for private channel and chat messages
  4. Soon a channel is migrated you should delete or archive
  5. Cross tenant access to channels is difficult to manage if not all members with access are migrated.


Summary and approach for a Teams Tenant-2-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. 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. This is ensuring your principals work, like admin accounts, permission, and other
  3. 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.
  4. 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.
  5. This is crucial, because every tenant is different in performance (location, user count, …)
  6. 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.


Comments

Post a Comment

Popular posts from this blog

How to hide users from GAL if they are AD Connect synchronized

-
Image
How to hide and un-hide users from Global Address List (GAL) in Exchange Online if they are AD Connect synchronized Hiding User from GAL isn't possible if those are synchronized form On-Premises Active Directory. The local AD is the leading system for all important attributes, like SMTP, UPN and hiding from GAL. Especially during a cross-tenant migration, you do not want to see not migrated user in the GAL. Those User aren't actively working until their cut-over day. Since the Exchange Online attribute  msExchHideFromAddressList s is an AD on-premises parameter, we have two possible ways hiding user in BME from GAL.   Modify the AD Connect for your teant with a custom rule, by using a extensionAttribute to set the HidefromGAL. In this rule, for users which have an entry in the extensionAttribute, hiding / un-hiding will be controlled by AD Connect This is the best option for Cross-Tenant Migration, if you run 2 or more AD Connect system We direct modif...
Read more

Cannot join external Lync Meeting: Lync Edge Server Single IP Address (Lync Edge Server Single IP Web Conferenceing Problem)

-
Image
Lync Edge Server FQDN and IP PORTS (Version 1.2, Update 26.11.2014) As we all know, we can configure Lync Edge Server in several way. 1) Single Edge Server with a SINGLE IP ADDRESS 2) Single Edge Server with MULTIPLE IP ADDRESSES (3x IPs) 3) Multiple Edge Server in a Pool, with MULTIPLE IP ADDRESSES (Zx 3 IPs) Regardless what we are going to configure, there are common / well-known TCP Port necessary making Lync work, which are: Access: Port: 443 and 5061 Conferencing: Port: 443 and (444) AV: Port: 443 (I have not listed other ports, e.g. STUN or the dynamic port range. This is not required for the topic discussed here) External FQDN with single IP address: What can we see here? If we are going to choose a single IP address, we would have TCP Port overlapping. Therefore the only way avoiding this is assigning other ports. Additionally we will also see and are reminded that Lync highly depends on DNS. If we have single IP, we must have use single, uniqu...
Read more

MFA with Guest Access and different tenants settings

-
Image
There is an update regarding MFA Multi Factor Authentication. If you are guest with a different Tenant, the MFA Settings are now reflecting the settings of all tenants in a different way. Each MFA setting is reflected and you can setup your MFA device as per tenant and the admin settings allow. Login to your Profile in Office 365/ Azure AD: https://account.activedirectory.windowsazure.com/r/#/profile or https://myapps.microsoft.com Go to your PROFILE: Sign in to https://myapps.microsoft.com Select your account name in the top right, then select profile. Select Additional security verification. If might be happen, your admin hast configured MFA, so you wouldn't see this menu. Simply switch the tenant to the guest tenant where you need to configure MFA. Once you go back to your profile and you will find the MFA device and other settings a usual:
Read more