#Preparation

Before the migration, you need to think about what object types they want to migrate. Refer to the .

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

To connect Fly to your Groups, 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:

Refer to to check the required permissions for Microsoft 365 Groups Migration.

#2. Run the source tenant discovery (optional)

Before you migrate from Microsoft 365 Groups, you can run a tenant discovery of Microsoft 365 Groups 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 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.

Refer to the .

#4. Assign license to users

If you want Fly to assign the Group 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. External users

External users cannot be migrated in the migration. You can export external users and import them into the destination tenant prior to the migration.

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

2. Run the PowerShell script to export the external users from the source tenant to a CSV file. (You can click the 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 to download the script.)

#6. Create Groups in destination tenant (optional)

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

#7. Handle large mail items for migration to destination mailboxes

Microsoft sets a default limit of 35 MB as the maximum size of a received message. We recommend increasing this to 150 MB before the migration to avoid any potential exceptions. Refer to to configure the limit.

Sample PowerShell command:

Set-unifiedGroup -Identity group@contoso.com -MaxReceiveSize 150MB

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

#9. Throttling limits

Microsoft uses throttling to manage Microsoft 365 operations and throttling limits will affect migration performance. Go to the Microsoft 365 admin center to lift the throttling restrictions.

1. Go to the Help (?) section of the Microsoft 365 admin center.

2. Enter EWS throttling as the search phrase.

3. Click Run Tests when you are asked to check your environment. Essentially, the tests check what EWS throttling applies to the tenant.

   

4. The support assistant checks the tenant settings and concludes that EWS is throttled (the normal situation). You will then be offered the chance to update the settings to the tenant EWS policy to lift throttling for 30, 60, or 90 days.

5. Select the number of days to adjust the policy, and then click Update Settings.

   

6. After a short delay, the support assistant will confirm that the settings have been changed.

#10. 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 Groups/emails/files to the destination, you need to create and publish the sensitivity labels in the destination before the migration. Refer to for details.

#11. Create source and destination connections

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

#12. Migration throughput

In Microsoft 365 Groups migrations, the job speed depends on the size of SharePoint team sites 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.

Mailbox Migration Throughput

Generally, a reasonable migration speed of the mailbox is 1.5 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.

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

There are many factors which may affect the migration performance:

#13. Prepare mapping files

Configure Groups mapping files and user mapping files: 

#14. Design the migration policy

A Microsoft 365 Groups migration policy allows you to define the migration scope of group objects, 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/Groups for Microsoft 365 Groups migrations. Refer to for details.

#15. Understand when destination users will receive notifications

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

Full/Incremental migration job

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

*Note: The notification results are the same for the following destination connection types:

Notification Type	User Type	Notification Results
Welcome Email	Internal User	If the destination Groups 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 Groups.If the destination Groups 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	If the destination Groups 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 Groups.If the destination Groups 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.
Task Comment Email	Guest User	Will receive notification if you select the Membership option in the migration policy. Will not receive notification if you deselect the Membership option in the migration policy.
Task Assign Email	Internal User	Will receive notification.
Task Assign Email	Guest User	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	If the destination Groups 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 Groups.If the destination Groups 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 365 Group. If the destination Groups are newly created by Fly in the migration, Fly will disable the welcome emails by default to avoid interruption. However, if the destination Groups already exist before the migration, Fly will not disable the welcome emails. You can manually disable the welcome emails.

*Note: To execute this PowerShell command, the following additional roles are required:

*Note: Even if you disable the email notification, the tasks’ Assign to users will receive the notification when the tasks are migrated to the destination.

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

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

3. Download the , 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 Groups 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.

#16. Plan a pilot run

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