Webcast Q&A Summary: The Truth About Tenant-to-Tenant Teams Migrations

Thank you to those who attended our May 6^th TEC Talk on tenant-to-tenant Teams Migrations which was led by myself, Technical Product Manager with Quest Software via Binary Tree; and Mike Weaver, Technical Product Manager with Quest Software via Quadrotech.

During that session, we drilled down into the granular details and important idiosyncrasies you’ll need to know for a successful tenant-to-tenant Microsoft Teams migration. We hope the information provided you with valuable insights into your current or future Teams migrations. In case you missed the live webcast, below is a high-level snapshot of what was discussed.

You can also watch the full TEC Talk on-demand here.

Challenges

We reviewed six key challenges facing every future Microsoft Teams migration project:

1. Usage & Sizing
2. Apps
3. API Limits
4. Archived & Deleted Teams
5. Custom SharePoint Content
6. Custom Team Templates

Coping Tactics

To help mitigate those challenges, we discussed six important coping tactics:

1. Teams Analytics & Reports
2. Restrict Apps & Bots
3. Identify Custom SharePoint Site Content
4. Staged vs Cutover
5. Turn off old usage
6. Priority order/limit the migration window

3 Things You Can Do Today

To prepare for success, we recommend that you take the following actions in the weeks or months prior to the data migration: 

1. Backup, Disable, Archive, or Remove Teams with no activity
2. Stop making the problem worse! No New Teams!
3. Set Team expiration and renewal policies to determine if Teams are required for migration

Want to know what Mike Weaver thinks is the the biggest thing missing from Microsoft’s APIs that would make tenant migrations easier? Make sure you check out this interview with him and Steve Goodman.

Questions & Answers

We’ve compiled all the great questions we received during the talk and summarized our answers just in case you missed anything.  If you have any additional questions, please ask them in the comments section.

1. Can private chats/channels be migrated between two tenants?
   
   Yes, both private channels and a user’s personal 1-on-1, group, and even meeting chat are now possible to migrate. There are of course some limitations, especially with private chat migrations. For example, one common constraint is that files must be migrated before the private chat to ensure any links to the file from the chat can be recreated during migration.
   
   
2. We currently have a situation where we need to migrate private and channel chats from one tenant to our own; is there a small, simple, cost-free solution available. If yes, which one?
   
   Microsoft presently doesn’t offer any native cost-free applications that migrate private channels and private conversations. We aren’t aware of any third-party freeware versions either.
   
   
3. What is the advised approach to migrate security settings in the whole environment – create new users and reapply the settings, or move both identities and security settings?
   
   To ensure security permissions remain intact in the target for all the various components, two solutions are key to success.
   
   First is directory synchronization, which can be used to migrate all your IAM objects between directories and keep them up to date for the entire lifecycle of the project. That includes new hires, leavers, and name changes. In addition, directory synchronization provides a means to reformat or transform object data on the fly to meet the new target’s standards and requirements. Directory synchronization prepares the target directory by replicating all the desired objects, to set the stage for future matching and permission migration operations for the various migration workloads.
   
   The final role that directory synchronization plays is end-user awareness. With directory synchronization services, you can manage which objects are visible in the Global Address Lists; who has personal contact information such as phone, title, or location; and which accounts should have guest access for Teams and SharePoint.
   
   The second key solution is the migration product itself. A mature tool will provide a method to create a mapping table, so source users and groups have a corresponding, unique match in the new directory.  Once the mapping is established, the migration tool should then set the different permission levels for the different objects at some point in the migration process.
   
   The migration product should also manage upper-level permissions such as mailbox delegation down to lower security layers such as folder permissions and file shares. For Teams, both the Teams and Channel roles should be migrated with proper mappings. However, there are additional permissions to be aware of that sit outside of Teams with regards to the SharePoint permissions. End-users may assign additional roles and extend access to files and folders that reside in the Team from SharePoint, so you need to keep this in mind when evaluating your Team’s migration solution.
   
   It should be noted that some organizations with a mature security posture may not allow tooling or a process to create accounts in the target tenant. For these organizations, they instead might have a formal automation system for creating accounts and managing them. In these situations, you’ll need to align with that tooling to bring over user attributes and settings with the migration tooling while working within the target security policy. 
   
   
4. If a tenant has Team chats set up with external clients will that be re-established when the user is migrated?
   
   To re-establish a chat with an external user in a newly migrated team, this will require another invitation to be sent to the Teams guest user which should be initiated by the team owner or an administrator when the time is right.
   
   To retain all guest permissions, the migration solution would be required to map the source and target guests to activate an invitation that’s sent during the cutover event. Once the Team is migrated and activated, the guest is notified by way of the new invitation, and they can then accept the invite.  
   
   This is an area where the migration team should conduct an inventory of external guests, that way they can send out new invitations when needed or request the team owner do so as a post-migration activity. It should also be noted that in these scenarios, the guest will have lost access to any previously shared content and this content must be re-shared.
   
   
5. What about tenant-to-tenant migration for Exchange data using an inbuilt Microsoft solution?
   
   The Microsoft Cross-Tenant mailbox migration feature is presently in public preview mode and should not be considered ready for critical enterprise migration projects. If you do adopt this migration method, there are some important constraints you should be aware of.
   
   Currently, there are certain technical limitations associated with the Batch Migration method (New-MigrationBatch) in particular, which is the present offering from Microsoft to facilitate mailbox moves between Office 365 tenants. 
   
   Primary Pain Points:
   – Expensive up-front setup costs.
   – Manually intensive script and spreadsheet management.
   – Complicated batch management.
   – Unmanageable end-user cutover experience.
   
   Tenant and Directory Preparation (Expensive) 
   The first obstacle you’ll face when trying to utilize Microsoft’s free Cross-Tenant Mailbox and Archive migration service is the initial configuration requirements. The client must first meet these requirements themselves, then arrange this set of complex configuration requirements in order to grant access between the tenants. From there, they must further coordinate these activities between both organization’s technical teams and execute individual scripts, adding to the overall project investment.   
   
   The second roadblock you’ll face is all the directory object preparation activities that must be completed prior to moving any mailbox data. This means that all target objects must be created in the target with all the specified attribute requirements set by Microsoft. For administrators to meet these requirements, this typically means they must write and test complex scripts or deploy and manage third-party directory synchronization solutions. Again, these types of activities in an M&A project must be coordinated and executed with an agreement between all parties. This alone adds additional layers of complexity and increases overall cost just to achieve the project’s goals.  
   
   Scripts and Spreadsheets (Manually Intensive) 
   The first set of challenges focused on the preparation of environments and directories, which requires a large upfront investment to successfully set up, validate and document. 
   
   Next, we’ll explore the challenges around migration management. When managing enterprise migration projects using a set of PowerShell commands and lists of mailboxes, it can quickly become cumbersome, error-prone, and manually intensive. Not only does this method require technical expertise in scriptwriting, management, and monitoring – but it also places an additional burden on the project team to manage and update long lists of usernames.
   
   Those lists must be conflict-free, grouped based on delegates, and fit within the end-users schedule – all of which can change daily and weekly. Therefore, this can become a very expensive team if all this technical expertise is required just to manage the daily processes of your migration project.   
   
   Batch Management (Complicated) 
   Our next challenge centers around the key limitation of using the Microsoft migration batch command. There are many known limitations to employing the New-MigrationBatch command to manage your mailbox migrations. However, the most challenging limitation is the requirement that mailboxes be grouped or batched based on their delegation relationships. This must be done to ensure that assigned permissions, Full Access, Send-As, and Send-on-Behalf settings are migrated. Otherwise, all those permissions are lost which impacts end-users the most. The end-user will be required to set up those permissions again, and in the meantime, their delegates are locked out of calendars and vital emails they may be responsible for. To meet Microsoft’s requirement to organize batches by delegation relationships is a daunting and expensive task to undertake for an organization of any size.  
   
   End-User Outlook Configuration (Unmanageable Cutover) 
   The final hurdle you’ll face when using the Microsoft Mailbox move methodology is the configuration of each user’s Outlook desktop application. Presently, the mailbox move technology does not support automatic configuration when moving a mailbox between tenants as it does for On-premises Exchange. This leaves the end-user stuck in the source without manual intervention, causing email downtime and loss of user productivity.  
   
   
6. Are there any strategies around voice migration from the source Teams environment to target Teams?
   
   You’ll need to work with your voice provider and Microsoft to build out a plan that will port over the existing phone numbers. Unfortunately, this is custom to each provider, country, and situation.
   
   
7. Is there a way to use both staged and cutover to address the challenges of each?
   
   There are circumstances when both big-bang and phased (or staged) migrations strategies can be leveraged effectively within the same project. In these scenarios, the organization may determine that conducting multiple mini-big-bangs based on site or location is the most efficient method to managing each event, whereby each site’s population is migrated in a single event and no coexistence services are deployed.
   
   With a staged migration project, coexistence services in some capacity are required to guarantee continued collaboration and access to data while some users live in the source and others in the target.  
   
   In both situations, be sure your support mechanisms are ready and can manage the amount of change occurring in the time allotted. If support is overloaded and the end-user is unhappy, it won’t matter which strategy you employ.
   
   
8. Are there multiple products needed for a Teams migration or will one product do the job, albeit with limitations?
   
   With many ISVs, multiple tools will be required because they generally specialize in a particular area. For example, one may provide your SharePoint migration services where another delivers mailbox migrations, but it’s not always the case. Some ISVs provide more comprehensive portfolios of solutions that meet all your present cross-tenant migration needs. That isn’t to say additional tools won’t always be needed, however, each client is different and some may have migration needs that require a more specialized tool to meet a specific need.  
    
9. Could you tell us what are the main advantages of using Quest instead of other software vendors?
   
   Quest On Demand offers the most comprehensive set of migration management solutions on the market. On Demand Migration covers all your major migration workloads such as accounts, Exchange Online, OneDrive, Teams and SharePoint Online all in one place, so there’s no need to purchase multiple tools to cover them all.
   
   Aside from managing all your migration workloads in a single application, you can also deploy coexistence services to support your migration including directory synchronization to prepare Identity and Access Management (IAM); automated mail flow to keep new mail flowing to the active mailbox; calendar sharing to maintain availability awareness; and domain sharing, allowing you to keep the email domain regardless of where the mailbox resides. 
   
   
10. What product(s) in the Quest portfolio are recommended for tenant-to-tenant migrations?
    
    Quest On-Demand Migrations provide the most comprehensive set of solutions to meet all your cross-tenant migration requirements. On Demand Migrations supports all your user’s migration workloads such as their account, mailbox, archive, public folders, files, folders, private chats, and now AD joined devices. All your shared workloads are also supported, such as Office 365 Groups, Teams, and SharePoint Site Collections.
    
    With any large migration, we recommend coexistence to prepare and keep your end-user collaborating no matter where they reside. This is why On Demand Migrations delivers a portfolio of integration solutions that maintain collaboration, access, and awareness between users while they are being moved. 
    
    
11. For a Teams migration, is it typically done as part of a full tenant migration of all other M365 services like Exchange Online, OneDrive, etc.? I’m doing my first tenant-to-tenant migration now and trying to coordinate the migration of a user’s mailbox, OneDrive, and any Teams they use is proving a challenge.
    
    When possible, it is best practice to move the user and all their corresponding workloads in tandem. To accomplish this, it is recommended that batches of users are built based on business-critical Teams’ membership. You should re-stage the user’s mail and file data along with the Team’s channels, files, and conversations. Prevent access to the target team until you are ready to cutover the entire batch of related users and their corresponding Teams, at which time the users’ client applications can all be reconfigured to access their data.
    
    If there are additional Teams that are less business-critical, those could be migrated afterward and at that time the users will automatically be notified when they are added as new members. For larger cutovers and projects, you should try to trim down or prioritize your Teams. For example, you can delay Teams without activity so you can focus migration efforts (including API time) on the active Teams.
    
    
12. Can I migrate Teams calling plans from tenant-to-tenant?
    
    There are no automated methods or APIs available to move any of these related calling plan components. This area must be managed manually and corraded at the correct time to ensure uninterrupted services. At best, there are a few PowerShell commands that allow phone numbers to be assigned to accounts.
    
    
13. What I’m seeing with the Teams client is if I migrate the user’s mailbox data to the new tenant, the Teams client on the calendar tab still connects to the mailbox in the old tenant meaning it has outdated information. Is this a limitation of the client or unique to my scenario?
    
    The Teams’ client will connect to the user mailbox of the tenant it is authenticating against. If the user is still logged into the source tenant within Teams, then the original mailbox calendar will be displayed.
    
    
14. What’s a good coexistence strategy for when users and Teams migrate at different times?
    
    Unfortunately, there is no industry standard in regards to Teams cross-tenant coexistence. The best strategy is to plan on avoiding coexistence by migrating Teams with the user’s mail and files.
    
    If that can’t be accomplished, one method to ensure continued access to source Teams resources after the user is migrated is to issue a Guest account for every migrated user. Once each migrated user has a guest account in the source, they may continue to access the Teams shared data using SSO with the new target account. When the Team is migrated, the source can be retired along with the guest account. Again, not the most ideal situation for the end-user but a plausible solution to a complex problem.
    
    
15. We are facing the same challenge for a customer who changed their business name shortly after we started the use of SharePoint with the old name in the primary domain header. We have been searching for an option to change it, but it looks like we ended up in a migration with a new start from tenant-to-tenant. Can someone tell me a different way to do it in place of the same tenant, as we would prefer this?
    
    Unfortunately, it isn’t possible to change the SharePoint domain name for your organization in Microsoft 365. For example, if the name of your organization changes from “Contoso” to “Fourth Coffee,” you can’t change contoso.sharepoint.com to fourthcoffee.sharepoint.com.
    
    To use the domain name fourthcoffee.sharepoint.com, you would need to purchase a new Microsoft 365 subscription and move all email, files, and any other data you want to keep to the new subscription.
    
    Click here for additional information. If you have additional follow-up questions, please post them in the comments below.
    
    You can watch the full webcast on-demand here.