#Microsoft Teams to Microsoft Teams Migration Process

The sections below contain the general migration process for Microsoft Teams to Microsoft Teams Migration. The details outlined in this document can serve as general guidelines with some minor adjustments.

• Preparation
• Migration Execution

More steps may be needed, and some steps included in the process may be optional according to your migration requirements.

#Preparation

Before the migration, you need to identify what object types you want to migrate. See the Supported and Unsupported List.

#1. Create a service account or app profile with required permissions

To connect Fly to your Teams, create a service account or an app profile with the required permissions in AvePoint Online Services. In general, you need to grant the following required permissions to the service account before the migration:

• Team Owner

• Licenses for Microsoft Teams and Exchange Online

• Owner of source private channels

• Mail Recipients roles

Refer to the latest Required Permissions to check the required permissions for Microsoft Teams Migration.

#2. Run the source tenant discovery (optional)

Before you migrate from Microsoft Teams, you can run a tenant discovery of Microsoft Teams to scan and report the object count, object type, object size, and other details. According to the discovery reports, you can better understand your source environment and plan for your migrations. Refer to the user guide for Tenant Discovery for details

#3. Create users in destination tenant or sync AD users

User mappings are required when executing migrations. Make sure users of the following data are created in the destination tenant before the migration.

• Team Membership

• Task: Assign To

• Conversation sent by

• Mail: To, Cc, Bcc, etc.

• File: Modified by and Created By

• Permission

• Other data that needs users

Refer to the user guide about how to prepare users.

#4. Assign license to users

If you want Fly to assign the Team Owner role to destination users in the migration, the users must have Microsoft 365 licenses. We recommend that you assign Microsoft 365 licenses to all destination users for easy use.

#5. Guest users

Guest users cannot be migrated in the migration. You can export guest users and import them into the destination tenant before the migration. The following actions are required:

• Export and import guest users.

  Refer to the following steps to export guest users and import them into the destination tenant:

  1. Make sure you have the Azure AD PowerShell Module installed before running the scripts. See instructions here.

  2. Run the PowerShell script to export the guest users from the source tenant to a CSV file. (You can click the link to download the script.)

  3. Run the PowerShell script to import the users in the CSV file to the destination tenant. (You can click the link to download the script.)

• Allow guest access in Teams.

  Refer to the following steps to allow guest access to destination Teams:

  1. In the destination Teams Admin Center, click Users in the left navigation, and click Guest access.

  2. Turn on Guest access.

     

#6. Create Teams in destination tenant (optional)

Fly can create Teams in the destination with the default domain of the destination tenant. If you want to create Teams without the default domain of the destination tenant, or you want to migrate to existing Teams, you can create Teams in the destination before the migration.

#7. Check destination retention policies

If retention policies are configured for the source data, check to make sure the destination retention policies are the same as the source retention policies. Otherwise, the destination data may be deleted due to different retention policies.

#8. Prepare sensitivity labels in destination (optional)

If the source tenant does not have sensitivity labels, you can ignore this step.

If the source tenant has sensitivity labels, and you want to keep the source sensitivity labels applied on Teams/emails/files to the destination, you need to create and publish the sensitivity labels in the destination before the migration. Refer to Create and publish sensitivity labels for details.

#9. Create source and destination connections

Refer to Create a Connection to connect Fly to your source and destination Teams. The connection including both the app profile and service account is recommended.

#10. Migration throughput

In Teams migrations, the job speed depends on the size of SharePoint team sites, the number of conversations, and the size of Group mailboxes.

SharePoint Site Migration Throughput

Generally, a reasonable SharePoint site migration speed is about 2 GB/hour/mapping. The number of mappings that run in parallel is automatically allocated based on your purchased subscription. The more subscriptions you purchase, the more mappings you can run in parallel.

Conversation Migration Throughput

Refer to the following cases for the Teams migration speed:

• If the destination connection has an app profile and the destination Teams are newly created during the migration, a reasonable Teams migration speed is 5000 messages/hour/mapping.

• If the destination connection does not have an app profile or the destination Teams already exist before the migration, a reasonable Teams migration speed is 1200 messages/hour/mapping.

The number of mappings that run in parallel is automatically allocated based on your purchased subscription. The more subscriptions you purchase, the more mappings you can run in parallel.

Mailbox Migration Throughput

Generally, a reasonable migration speed of the mailbox is 1.5 GB/hour/mapping. The number of mappings runs in parallel is automatically allocated based on your purchased subscription. The more subscriptions you purchase, the more mappings you can run in parallel.

We can calculate how much content can be migrated with the above infrastructure.

There are many factors which may affect migration performance:

• The above throughput number is for the full migration. Generally, it may be lower for the incremental migration since Fly needs to spend quite some time checking the migrated items’ status for the incremental migration.

• The above results are only ideal values after many tests. The migration speeds of different tenants may be different. We recommend that you estimate the daily throughput in the same way as the results of the pilot job.

• If your Planner is particularly large, the overall migration speed may be slowed down.

#11. Prepare mapping files

Configure Teams mapping files and user mapping files:

• Examples in the Teams mapping file

  

• Examples in the user mapping file

  

#12. Design the migration policy

A Microsoft Teams migration policy allows you to define the migration scope of Team objects, the destination format of channel conversations, the conflict resolutions, whether to replace source email addresses/meeting links with destination, how to map users, and how to manage the sensitivity labels of files/emails/Teams for Microsoft Teams to Microsoft Teams migrations. Refer to Create a Migration Policy for details.

By default, Fly will automatically complete the destination Teams, which are newly created during the full migration job. If you want to disable the auto complete, you can configure the AutoCompleteTeams=false customized feature string in the migration policy. After all of the messages are migrated to destination Teams, you can manually complete the destination Teams by running the Complete migration job. Refer to Understand Migrations before Getting Started and Customized Features for Microsoft Teams Migration for details.

#13. Understand when destination users will receive notifications

In some situations, destination users will receive email notifications when they are added to destination Teams or source objects are migrated to destination users.

• Will not receive welcome emails if

  • the destination Team is newly created by Fly during the migration.

  • the destination is an existing Team, which was created via the Teams app via the From template or From another team method.

  • the destination is an existing Team, which was created from the Teams admin center via the Add a team method.

• Will receive welcome emails if

  • the destination is a Microsoft 365 Group without Teams added. (In this case, Fly will automatically enable a Team for the Group during the migration.)

  • the destination is an existing Team, which was created via the Teams app via the From group method.

For more detailed information, refer to Full/Incremental migration Job.

#Full/Incremental migration Job

The table below shows specific situations when destination users will be notified.

Notification Type	User Type	Destination Connection: Service Account Authentication Only	Destination Connection: App Profile Only (Destination Teams are newly created during the migration)	Destination Connection: Service Account Authentication and App Profile (Destination Teams are newly created during the migration)	Destination Connection: Service Account Authentication and App Profile (Destination Teams already exist before the migration)
Team Activity Notification: User mentioned in Teams	Internal User	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	Will not receive notification.	Will not receive notification.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.
Team Activity Notification: User mentioned in Teams	Guest User	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	Will not receive notification.	Will not receive notification.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.
Team Activity Notification: User added to Teams	Internal User	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.
Team Activity Notification: User added to Teams	Guest User	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.
Welcome Email	Internal User	1. If the destination Teams are newly created by Fly during the migration, Fly will disable the welcome emails and the destination users will not receive any welcome emails when they are added to destination Teams. 2. If the destination Teams already exist before the migration, Fly will not disable the welcome emails for the destination users. You can manually disable welcome emails for them. Refer to Disable welcome emails (optional) for details.	1. If the destination Teams are newly created by Fly during the migration, Fly will disable the welcome emails and the destination users will not receive any welcome emails when they are added to destination Teams. 2. If the destination Teams already exist before the migration, Fly will not disable the welcome emails for the destination users. You can manually disable welcome emails for them. Refer to Disable welcome emails (optional) for details.	1. If the destination Teams are newly created by Fly during the migration, Fly will disable the welcome emails and the destination users will not receive any welcome emails when they are added to destination Teams. 2. If the destination Teams already exist before the migration, Fly will not disable the welcome emails for the destination users. You can manually disable welcome emails for them. Refer to Disable welcome emails (optional) for details.	1. If the destination Teams are newly created by Fly during the migration, Fly will disable the welcome emails and the destination users will not receive any welcome emails when they are added to destination Teams. 2. If the destination Teams already exist before the migration, Fly will not disable the welcome emails for the destination users. You can manually disable welcome emails for them. Refer to Disable welcome emails (optional) for details.
Welcome Email	Guest User	1. If the destination Teams are newly created by Fly during the migration, Fly will disable the welcome emails and the destination users will not receive any welcome emails when they are added to destination Teams. 2. If the destination Teams already exist before the migration, Fly will not disable the welcome emails for the destination users. You can manually disable welcome emails for them. Refer to Disable welcome emails (optional) for details.	1. If the destination Teams are newly created by Fly during the migration, Fly will disable the welcome emails and the destination users will not receive any welcome emails when they are added to destination Teams. 2. If the destination Teams already exist before the migration, Fly will not disable the welcome emails for the destination users. You can manually disable welcome emails for them. Refer to Disable welcome emails (optional) for details.	1. If the destination Teams are newly created by Fly during the migration, Fly will disable the welcome emails and the destination users will not receive any welcome emails when they are added to destination Teams. 2. If the destination Teams already exist before the migration, Fly will not disable the welcome emails for the destination users. You can manually disable welcome emails for them. Refer to Disable welcome emails (optional) for details.	1. If the destination Teams are newly created by Fly during the migration, Fly will disable the welcome emails and the destination users will not receive any welcome emails when they are added to destination Teams. 2. If the destination Teams already exist before the migration, Fly will not disable the welcome emails for the destination users. You can manually disable welcome emails for them. Refer to Disable welcome emails (optional) for details.
Task Comment Email	Internal User	Will not receive notification.	Will not receive notification.	Will not receive notification.	Will not receive notification.
Task Comment Email	Guest User	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.	1. Will receive notification if you select the Membership option in the migration policy. 2. Will not receive notification if you deselect the Membership option in the migration policy.
Task Assign Email	Internal User	Will receive notification.	Will receive notification.	Will receive notification.	Will receive notification.
Task Assign Email	Guest User	Will not receive notification.	Will not receive notification.	Will not receive notification.	Will not receive notification.

#Migrate membership job

The table below shows specific situations when destination users will be notified.

Notification Type	User Type	Migrate Membership Job
Welcome Email	Internal User	1. If the destination Teams are newly created by Fly during the migration, Fly will disable the welcome emails and the destination users will not receive any notifications when they are added to destination Teams. 2. If the destination Teams already exist before the migration, Fly will not disable the welcome emails for the destination users. You can manually disable welcome emails for them. Refer to Disable welcome emails (optional) for details.
Welcome Email	Guest User	Will not receive notification.

#Disable welcome emails (optional)

Generally, users will receive welcome emails if they are added as members of a Microsoft Team. If the destination Teams are newly created by Fly in the migration, Fly will disable the welcome emails by default to avoid interruption. However, if the destination Teams already exist before the migration, Fly will not disable the welcome emails. You can manually disable the welcome emails.

Refer to the following steps to disable or enable the welcome emails:

1. Install the Exchange Online PowerShell V3 module to the server where you will run the DisableAndEnableGroupWelcomeEmail.ps1 file. Refer to Install Exchange Online PowerShell V3 module for details.

2. Connect the Exchange Online PowerShell V3 module to Exchange Online. Refer to Connect to Exchange Online for details

3. Download the GroupWelcomeEmail.zip, and extract the ZIP file to a location with a network connection.

4. In the extracted tool folder, open the Template.csv file, and configure the email addresses of Teams for which you want to disable welcome emails.

5. Right-click the DisableAndEnableGroupWelcomeEmail.ps1 application file, and select Run with PowerShell.

6. Enter your credentials, and click OK to open the PowerShell window.

7. Enter the full path of the CSV file configured in step 4, and press Enter on the keyboard.

8. To disable the notifications, enter option 1 and press Enter on the keyboard.

   To enable the notifications, enter option 2 and press Enter on the keyboard.

#14. Plan a pilot run

We recommend you perform a pilot run for the following purposes:

• Get familiar with the Fly interface and understand the whole migration process.

• Discover and resolve any potential issues before production migration.

• Understand the throttling situation in case content size is large, and then try to resolve with the destination.

#Migration Execution

Refer to the following sections to execute the migration based on the migration modes.

• Classic mode – The destination connection does not have an app profile or the destination Teams already exist.

• Advanced mode – The destination connection has an app profile and the destination Teams need to be created during the migration.

#Classic Mode

Refer to the following sections to execute the migration with the classic mode:

#1. Configure projects and mappings in Fly

To configure projects and mappings, refer to Create a Project and Create Migration Mappings for details. Use the mapping file of data to be migrated to configure the migration project.

#2. Perform regular full migrations

Before running the job, we recommend you verify the mappings to ensure that the mappings are available for migration. Refer to Pre-analyze Mappings for details.

Then you can run a full migration job to migrate the objects based on your configured migration policy. Refer to Run Migrations to Migrate Objects for details.

#3. Perform regular incremental migrations

Some issues may occur during a full migration job. Run an incremental migration job to handle new, updated, and failed data. Refer to Run Migrations to Migrate Objects about how to perform regular incremental migrations.

#4. Communicate with end users (optional)

Notify end users of the migration schedule. Publish a message in each source Team to inform end users that they can run incremental jobs before final validation.

#5. Perform the final incremental migration and migrate membership

Notify all users and make sure the source Teams do not have any new/modified objects. Then perform the final incremental migration job.

After you complete your migrations but the source membership is not included in the migrations, to make the destination Team available for users, you can run a Migrate membership job to only migrate the source membership, including owners, members, and guests. Refer to the user guide for details.

#6. Compare the source and destination storage (optional)

After the migration, you can compare the number and size of files in the source and destination team sites by accessing the following URL:

sitecollectionurl/_layouts/15/storman.aspx

• If the number of files is different after the migration, check if the files that are not in the destination are migrated. If the files have not been migrated, check the comments of error files. After you fix the errors, rerun the migration job. If there are no records for these files, contact Support and provide the screenshots of these files and job ID to analyze the error.

• If the size of files is different after the migration, for example, the source file size is 10 MB, but the migrated file size is 100 MB, check the actual size of the source and migrated files in the source and destination libraries. Then, refer to the following instructions to resolve this issue:

  • If the actual size of the source file is 10 MB, the actual size of the migrated file is 10 MB, but the migrated file size displayed in the destination Storage Metrics page is 100 MB, it may be an issue of Microsoft.

  • If the actual size of the source file is 100 MB, the actual size of the migrated file is 100 MB, but the source file size displayed in the Storage Metrics page is 10 MB, it may be an issue of Microsoft.

  • If the actual size of the source file is 10 MB but the actual size of the migrated file is 100 MB, it is an issue of Fly. Contact Support and provide the screenshots of version histories of the source and migrated files, and screenshots of the Storage Metrics pages of the source and destination by accessing the following URL to analyze the error:

    sitecollectionurl/_layouts/15/storman.aspx

#7. Validate migration results

Check the following items during the validation period:

• Number of messages

• Number of files

• Number of tabs

• Number of mails in Group mailbox

• Number of planners and tasks

• Format of conversations and HTML files

#8. Perform migrations for all other waves (optional)

This step is needed only if you have separated the mappings into multiple waves.

#9. Perform the final validation

During the final validation, you should validate members of the destination Teams and destination private channels.

#10. Change domain

After you finish your migrations for the current wave, if you need to keep the source domain to the destination, you can change the domains of your source and destination environments.

Refer to the following steps for details:

1. Remove the domain from the source tenant.

   To remove a domain from a Microsoft 365 tenant, refer to the Microsoft Document: Remove a domain.

2. Add the domain to the destination tenant.

   To add a domain to a Microsoft 365 tenant, refer to the Microsoft Document: Add a domain to Microsoft 365.

3. Add the new destination email address as an alias of the destination user and set the new email address as the primary email. This ensures that destination users can use the new email addresses.

4. Then, if you want to perform a final incremental migration to migrate the new or modified data to the destination, you must update the domain names of the source and destination Team email addresses in Fly first. Refer to the user guide for Change Mapping Domain for details.

#Advanced Mode

Refer to the following sections to execute the migration with the advanced mode:

#1. Configure projects and mappings in Fly

To configure projects and mappings, refer to Create a Project and Create Migration Mappings for details. Use the mapping file of data to be migrated to configure the migration project.

#2. Perform regular full migrations

Before running the job, we recommend you verify the mappings to ensure that the mappings are available for migration. Refer to Pre-analyze Mappings for details.

Then you can run a full migration job to migrate the objects based on your configured migration policy. Refer to Run Migrations to Migrate Objects for details.

#3. Perform regular incremental migrations

Some issues may occur during a full migration job. Run an incremental migration job to handle new, updated, and failed data. Refer to Run Migrations to Migrate Objects about how to perform regular incremental migrations.

#4. Communicate with end users (optional)

Notify end users of the migration schedule. Publish a message in each source Team to inform end users that they can run incremental jobs before final validation.

#5. Perform the final incremental migration and migrate membership

Notify all users and make sure the source Teams do not have any new/modified objects. Then perform the final incremental migration job.

#6. Run a complete migration job and migrate membership (optional)

If you have disabled the auto complete by adding the AutoCompleteTeams=false customized feature, you need to manually run the Complete migration job after all migrations are finished to make destination Teams available for end users. Refer to Complete Migration for details.

After you complete your migrations but the source membership is not included in the migrations, to make the destination Team available for users, you can run a Migrate membership job to only migrate the source membership, including owners, members, and guests. Refer to the user guide for details.

#7. Perform incremental migrations for other waves (optional)

If there are new or modified objects in the source after the complete job, you can perform the incremental migrations to make sure all source changes are migrated to the destination.

#8. Compare the source and destination storage (optional)

After the migration, you can compare the number and size of files in the source and destination team sites by accessing the following URL:

sitecollectionurl/_layouts/15/storman.aspx

• If the number of files is different after the migration, check if the files that are not in the destination are migrated. If the files have not been migrated, check the comments of error files. After you fix the errors, rerun the migration job. If there are no records for these files, contact Support and provide the screenshots of these files and job ID to analyze the error.

• If the size of files is different after the migration, for example, the source file size is 10 MB, but the migrated file size is 100 MB, check the actual size of the source and migrated files in the source and destination libraries. Then, refer to the following instructions to resolve this issue:

  • If the actual size of the source file is 10 MB, the actual size of the migrated file is 10 MB, but the migrated file size displayed in the destination Storage Metrics page is 100 MB, it may be an issue of Microsoft.

  • If the actual size of the source file is 100 MB, the actual size of the migrated file is 100 MB, but the source file size displayed in the Storage Metrics page is 10 MB, it may be an issue of Microsoft.

  • If the actual size of the source file is 10 MB but the actual size of the migrated file is 100 MB, it is an issue of Fly. Contact Support and provide the screenshots of version histories of the source and migrated files, and screenshots of the Storage Metrics pages of the source and destination by accessing the following URL to analyze the error:

    sitecollectionurl/_layouts/15/storman.aspx

#9. Validate migration results

Check the following items during the validation period:

• Number of messages

• Number of files

• Number of tabs

• Number of mails in Group mailbox

• Number of planners and tasks

• Format of conversations and HTML files

#10. Perform migrations for all other waves (optional)

This step is needed only if you have separated the mappings into multiple waves.

#11. Perform the final validation

During the final validation, you should validate members of the destination Teams and destination private channels.

#12. Change domain

After you finish your migrations for the current wave, if you need to keep the source domain to the destination, you can change the domains of your source and destination environments.

Refer to the following steps for details:

1. Remove the domain from the source tenant.

   To remove a domain from a Microsoft 365 tenant, refer to the Microsoft Document: Remove a domain.

2. Add the domain to the destination tenant.

   To add a domain to a Microsoft 365 tenant, refer to the Microsoft Document: Add a domain to Microsoft 365.

3. Add the new destination email address as an alias of the destination user and set the new email address as the primary email. This ensures that destination users can use the new email addresses.

4. Then, if you want to perform a final incremental migration to migrate the new or modified data to the destination, you must update the domain names of the source and destination Team email addresses in Fly first. Refer to the user guide for Change Mapping Domain for details.