Teams to Teams Migration: How to Handle the Discovery Phase

The following is an excerpt from our latest Microsoft Teams ebook, “The World’s Most Comprehensive Teams to Teams Migration Checklist.” Check out other excerpts below:

• How to Prepare for a Microsoft Teams to Teams Migration Pilot
• How to Navigate the Microsoft Teams Migration Planning Process

Discovery is the most important phase of a migration, and a robust process will give you the greatest likelihood of long-term success in your new environment.

While it’s tempting to focus on content — what, where, owner, structure, importance — a complete discovery process for a Teams to Teams migration also focuses on information architecture, configurations, permissions, and users/licenses.

The Discovery Process:

1. Review your project requirements and capabilities to determine which vendor you will use and if you will migrate yourself or contract services.
2. Access a trial of AvePoint’s FLY migration tool and run a full automated content discovery at no cost. You can also watch this three-minute video to learn how to run a pre-migration discovery report. Keep in mind, you will need to set up a connection to your source environment to do a discovery report.
3. Use the results from your pre-migration discovery to determine what information architecture changes will need to be made.
4. Either access multiple admin centers in both source and target tenant to record settings and note disparities or leverage a solution like Elements Pro (beta).
5. Navigate to the Microsoft 365 admin center and navigate to billing to view the number of assigned licenses to individual users. Note: If you want deeper insight into how those licenses and premium licenses are being used a tool like Cense can help optimize your license allocation and budget in your destination tenant.

Determining Your Migration Approach

If you need to migrate anything other than files and mailboxes, Microsoft’s free cloud migration tool or scripting is not for you. If you are looking to migrate advanced workloads such as conversations, you will want to select a migration vendor like AvePoint that leverages Microsoft’s import API to ensure you are able to have full data fidelity and scale.

Some vendors, such as AvePoint, can migrate tabs and wikis but some types of apps or customizations may have to be rebuilt in the new environment. If your deadline is tight or your team does not have extra capacity, migration services might be more effective than launching the project yourself. Finally, AvePoint is one of only a few vendors that migrate Planner boards or private chats.

Content and Workflow Considerations

There are many factors that impact migration, but the number of items — channels, users, tasks, threaded conversations, etc. — and size of the associated files will determine how long a migration job will take. How you choose to divide those jobs will depend on your organizational structure and/or importance of the content.

You can greatly reduce the time and cost of your migration by not including redundant, obsolete or trivial information as part of your migration. This information can be archived or deleted as appropriate (most organizations choose to archive).

Refactoring critical business processes/workflows/apps as well as remediating issues that come up from ownerless Teams or how to handle sensitive data will add time to your migration project and will need special attention. AvePoint FLY allows for sensitivity labels to be automatically applied to the newly migrated data if that label exists in the destination environment. Communicating with business owners will be critical to making smart decisions.

Information Architecture Considerations

Careful consideration should be given prior to launching a lift and shift migration for a Teams to Teams migration. That’s because instead of moving a shared collaboration structure to the cloud, you are merging two collaboration structures — and without understanding how the pieces fit together you will get a disorganized environment that will impact user productivity, adoption and satisfaction.

For example, it’s likely the source and target destination have two different naming conventions; one might have the business unit as a prefix and the other might have the sensitivity. So, the Team for public relations in Tenant A might be MKT Public Relations_ External and the same Team in Tenant B might have been labeled Confidential Public Relations_External. Naming conventions will need to be remediated, users trained, and oftentimes common Teams mapped and merged.

This can be done during the migration with a tool like FLY, but it is also a best practice to consider leveraging a governance tool like AvePoint Cloud Governance or Policies and Insights that can enforce naming conventions during the provisioning and lifetime of the Group/Team.

To find information on the structure of your Teams, you can use the FLY discovery tool (example report below) or the Microsoft Teams admin center.

Settings and Access Considerations

The first instinct for many organizations, if they are proactively thinking about governance and security at all, is to assume the settings and policies in the source tenant will get overwritten by the settings and policies in the target tenant. This thinking is especially prevalent when the tenant to tenant migration is being driven by M&A activity. However, this simplification will often create issues.

There may be legitimate business or regulatory reasons why one Microsoft Teams environment was configured differently. Perhaps, users in the source tenant had Teams that contained content subject to ITAR restrictions that required more restrictive external sharing policies for example.

While Microsoft 365 and Microsoft Teams does have a number of “one tenant one rule” settings, third-party tools like AvePoint Cloud Governance can tailor those settings to the needs of different working groups at scale. Either way, understanding, evaluating and remediating the differences between target and source configurations is a must.

Additionally, if settings were overly lax in the source tenant (say anonymous links were enabled), sensitive data permissions may need to be evaluated and handled in a more compliant manner. It is a best practice to fix any permission issues in the source tenant prior to migrating.

To learn about user and license considerations and gain access to comprehensive planning checklists, be sure to download the full ebook here.

For all things Microsoft Teams don’t forget to subscribe to our blog.