Increase the success of your migration by following these recommended best practices for G Suite Migrate.
Before a migration
- Adhere to the system requirements—Migrations require a lot of resources. Meeting or exceeding the system requirements is crucial because new resources cannot be provisioned while a migration is in progress. Learn more
- Use Google Cloud Platform—Google extensively tested G Suite Migrate on Google Cloud Platform (GCP). We have the most experience supporting migrations in GCP, including provisioning the network and VMs to the required specifications.
- Reduce network latency—Connect servers on the same network in close physical proximity to reduce network latency and improve performance.
If you use Google Compute Engine inside GCP, you might want to choose a region or zone that is close to your point of service to decrease network latency. For example, you might want to choose the primary region and zone closest to your data sources.
- Set Chrome Browser as the default—Both G Suite Migrate and GCP have been extensively tested on Chrome Browser. Learn more
- Disable automatic Windows updates—To prevent an unintended restart of your servers during a migration, manage Microsoft® Windows® updates outside of running migrations.
- Set up the correct number of worker nodes—The number of worker node servers deployed should match the number of users in your organization and the amount of data to migrate. The size and complexity of your migration phases should match your organization's goals to ensure you have provisioned enough nodes to meet them. Generally, deploying more worker nodes results in faster migrations. Learn more
- Limit worker nodes to 40 per cluster—For large G Suite migrations, the maximum number of worker nodes is 40. These 40 nodes combine to create a cluster. You can deploy multiple clusters for a migration.
Note: Clusters are self-contained and do not share databases, nodes, or platforms. Therefore, migration data sets on different clusters should be as mutually exclusive as possible.
- Set up the correct digital certificate—G Suite Migrate uses TLS certificates as its cryptographic protocol. TLS is used to configure the G Suite Migrate platform and node servers. Google does not support self-signed certificates at this time. Learn more
- Scan your data—We recommend a full data scan prior to a migration. A full scan runs faster than a migration and it provides the following benefits:
- Reports with an estimation of the corpus size, the type of source data, and any issues with the data.
- Optimization of workload distribution across worker nodes.
- Prioritization of large individual data sets that require serial processing (such as users with extremely large numbers of emails). In turn, large data sets do not become migration bottlenecks.
- Set up a new project when you are ready to migrate data—Reusing a test project can cause data to be skipped if it was previously migrated in a test phase. G Suite Migrate recognizes that the data has already been migrated and doesn’t migrate it again. After you complete testing, use a new project to avoid this issue.
During a migration
When migrating files to Drive, we recommend:
- Split the migration into multiple target locations, for example, My Drives belonging to different users or separate shared drives.
- If possible, specify multiple Drive users in your mapping. This spreads the load of the migration across a larger group of users and helps avoid quota issues.
- Migrate to shared drives so that all team members can access your organization’s resources. See Best practices for shared drives.
- Consolidate multiple user shares to Google Groups to easily manage shared drive membership and communicate announcements to a group.
- Eliminate folder hierarchies where possible.
There are some limits to the size and types of data you can store in Drive. See Files you can store in Google Drive.