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:
At this stage, you should be confident that you have all the information you need. You’ve spoken with the business and have a good understanding of how the new tenant will be operating and what appropriate governance policies will look like. You’ve launched a pilot migration and have a good understanding of what will migrate and how quickly.
Now, it’s time to finalize our plan and make some initial preparations to ensure our people, processes, and technology are all in alignment.
How to Prepare:
- Create a Microsoft Teams information architecture plan for the target tenant based on your discovery and in accordance with the desired governance
- Make any required changes to permissions and information architecture as you can in your source tenant; this will make migrating to the destination tenant easier and require less post-migration Determine what solutions you will need to leverage in the target tenant to tailor settings to different groups (optional) and rebuild/integrate customizations/apps/workflows as necessary into Teams that are already established (a merger vs. moving a source Team into the target environment as a net new Team). Add users and assign licenses in the target destination prior to any migration activities. Backup and perform a test restore of both target and source tenants.
- Group your source Teams into migration Put full and incremental migrations on a timeline along with the final cutover.
- Create your migration mappings, filters, and policies based on your planned Teams structure and migration.
Understanding how the business will work in the new environment will be critical to the structure, naming conventions, and governance structure you will be implementing.
In many cases, this migration project has been launched with the need to more fully integrate and work together as a team. In this case, your planned architecture should include merging more Teams together. It would not make sense to have a “Source Tenant Finance” Team and a “Target Tenant Finance” Team in the new environment if these business groups were expected to work together closely.
On the other hand, there are scenarios where a Teams to Teams migration will make collaboration a bit easier and more secure across the organization, but there is still a desire to maintain a somewhat more separated Team infrastructure. For example, an organization may acquire another with the intention of operating them as very distinct units and brands. Or in the case where two tenants across different geographies are merging, the marketing team may want to create a combined Team for the whole business unit, but maintain their separate regional Teams as well.
Once you understand the overall structure of your Teams environment and business collaboration needs, you can decide on governance policies and settings. It is possible to tailor some settings to the type of Team workspace using native functionality across multiple admin centers, although maintenance and enforcement can be tedious. For example, for every requested internal Team, an admin can use Powershell to disable guest access for that specific workspace (note other settings will need to be modified).
Automated tools like Cloud Governance can greatly expedite the process. On the other hand, Microsoft 365 does have some “one-tenant one rule settings,” such as if the creation of a workspace can be self- provisioned by the user or if it needs to be provisioned by a designated party. Cloud Governance can also be used to tailor these rules by department or any other desired AD setting.
For more Teams to Teams migration insights including how to navigate source tenant preparation, be sure to download the full ebook here.