Monitoring points for Google to Google migrations

If you haven’t yet, review the Google Workspace Migrate best practices first.

Before you begin a Google Workspace to Google Workspace migration, review the following points for email, Google Calendar, Google Drive items, shared drives, and other types of data.

Email & email addresses  |  Calendar data  |  Drive  |  Shared drives  |  Other types of data

Email & email addresses

Email forwarding
To avoid duplicates and errors, email messages are checked to make sure they don’t already exist in the target mailbox. If you use email forwarding and enable the Accelerate old messages setting, set the Insert Before Date field to the day before forwarding was turned on to reduce the risk of data duplication. For details, go to Understand scan reports.
Links in email messages
Gmail scans migrated email messages for security and threat issues and occasionally crawls links in the body of email messages. To avoid this issue and modestly increase migration performance, you can use the Accelerate old messages option in your settings template. Before you do, review how it works. For details, go to Migrate Mail content.
Changing a user’s email address
Once you start migrating a user's content, we recommend that you don’t change their email address. If you change an address during or after a migration and then run a delta migration, Google Workspace Migrate remigrates all of the user's content, making the delta process significantly slower than usual.
Label colors
Only standard label colors are supported. Labels with custom colors don't migrate. If you get an error, remove the custom colors from labels in the source account and try again. For details about standard label colors, go to Gmail API: Color.

Calendar data

API limits
If you’re running a large migration (1,000+ calendars), you might reach the Google Calendar API daily limit and see 403 errors. You can request an increase to the query per minute (QPM) limit for the Calendar API: Run a scan to get the total number of events and users that you need to migrate. Determine how many users you're likely to migrate at the same time. Request a Calendar API QPM quota of 160 times that amount. For details, go to Requesting a higher quota limit. Make sure that your per minute write operations don't exceed 60 QPM. The rate limit for write operations can't be increased.
Use an identity mapping
Use an identity mapping to: Transfer calendar resources Map an event organizer, when the organizer is external to your organization For details, go to Create & manage an identity mapping.
Auto-accepted meetings
If the calendar resource is set to Auto-accept meetings that don't conflict (the default) and conflicting bookings are migrated, the meeting organizer gets an email for each declined invitation. The super administrator account used to migrate the resource also receives an email. To use content compliance rules to deliver these messages to email quarantines, go to Set up rules for advanced email content filtering.
Migrate using super administrator accounts
By default, Google Workspace Migrate uses all super administrator accounts to write calendar resource events to the target domain. Using super admin accounts increases migration speed and reduces the risk of quota issues. Note the following points: At least 24 hours before you run a migration, create the super admin accounts and assign privileges. For details, go to Prebuilt administrator roles. All super admins must have the Google Calendar service turned on. Otherwise, you'll get failures in your migration. For details, go to Turn a service on or off for Google Workspace users. Following a migration, the resource event shows as "Created by" the super admin. The activity is tracked in the Calendar audit log.

Drive

Large single-user migrations
A migration of 400,000 files or more to one user's Google Drive account requires extra planning. Use a sharding users list to spread the migration load among many user accounts. To determine the number of user accounts to add to the list, use the larger value of: One account per 400,000 files that are being migrated to Drive 10 accounts per node We recommend you set up temporary Google Workspace users for your sharding users list. Then, delete the users after you complete the migration. For details, go to Create a sharding users list.
Comments in Google Docs
Comments get copied along with the files. Following a migration, a note is added that the comments were copied.  Copied comments and comments that mention a user (using @email-address in the comment) remain associated with the original users on the source account. Replies to a copied comment don't trigger notifications to users mentioned or the user who created the original comment. To associate copied comments to a new account, manually update comments with the new email address.
Content shared with users outside of your organization
If users or groups outside of your organization have a Google Account, you can add them to Drive files and folders and migrate sharing permissions. External users or groups without a Google Account can receive an email with a custom access link at migration time. To reduce the amount of time that users without a Google Account have access to shared files and folders: Migrate shared content during the final incremental migration. In your Google Admin console, turn on file sharing for people outside of your organization. For details, go to Set Drive users' sharing permissions. In the settings template, turn on Allow email invitations to send an invitation with a link to the shared content. For details, go to Migrate Drive content. Tip: Use the Permissions by Object report to identify externally shared objects before a migration. For details, go to Understand scan reports.
Links in migrated Drive files
Links in Google and non-Google files must be corrected manually after a migration.
Running test migrations to Drive
If you delete items in the target Drive account following a test migration, make sure to empty the trash before rerunning the migration. Google Workspace Migrate tracks items by ID and restores items from the target account's trash if you run the migration again. Emptying the trash avoids this issue and allows you to run a fresh migration.
General access options & target audiences
Google Workspace Migrate migrates the sharing permissions of items that are saved to Drive using the: General access default option Default target audience sharing permissions (but not permissions for custom target audiences) To migrate permissions for the default target audience, include the source and target domains in the identity mapping, for example, example.com,solarmora.com. For more information, go to: Set the general access default option for new items About target audiences
Migrating files & folders to multiple locations in Drive
Google Workspace Migrate attempts to remigrate a file or folder to a new location in Drive if: You're migrating from Drive and the source item has more than one parent. The item is moved on the source or target account and then remigrated. The item's target location is changed in a mapping, and the item is remigrated. The outcome of the remigration depends on the item's existing and new locations. If both locations are in My Drive or in the same shared drive, the item is moved to the new location. Otherwise, the item is not moved and the transaction fails with error code 1081344.
Orphaned content
During a migration, Google Workspace Migrate migrates orphaned items (items that are unorganized or residing in folders that the user doesn't own) in the source account to the target owner's My Drive root. To map orphaned content to a different destination, use the mapping to specify an existing Drive folder on the target account. If you want to create and map items to a new folder on the target account, use the Sub Path header in the mapping. For detailed examples, go to Common examples of mappings. You can also manually map a user's Drive service, including orphaned content, to a target user's My Drive using the Google Workspace Migrate platform.
Externally owned files in a user's My Drive
Files that both reside in a user's My Drive and are owned by a user outside of your organization aren't migrated. The Shared content by user report does not show these files.
API limits
If you're running a large migration, you might reach the Google Drive API daily limit and get 403 errors. For details about API limitations, go to Usage limits. You can request an increase to the query-per-minute limit for the Drive API. For more information, go to Requesting a higher quota limit. Depending on your Google Workspace edition, you might have additional Drive storage limits. For details, visit Storage and upload limits for Google Workspace.

Shared drives

Migrating to shared drives
You can’t migrate content to a user's My Drive and any shared drives in one migration. You must run the migrations separately. You can only migrate shared drive content to another shared drive. You can't migrate shared drive content to a user's My Drive. Only managers of the shared drive are used to write files. Therefore, large shared drives with only a few managers might migrate slowly. If you’re migrating to shared drives, you must use a shared drives settings template. Learn more about settings templates.
Mapping shared drives
For detailed information about Google Workspace mappings, go to Create & manage a mapping. When mapping a shared drive: If you're mapping between shared drives, use an identity mapping, even if the shared drives have the same manager. Explicitly map a user's shared drive. Mapping a user or the Drive service won't migrate content to a shared drive. Don’t map a single shared drive to multiple users. If the shared drive doesn’t currently exist on the target account, specify the root of the user’s shared drive as the mapping target. You must also make sure that Map content only is turned off when creating the mapping. After a migration, the target user is displayed as the creator of the shared drive. If the shared drive exists on the target account, make sure the mapping contains both the source and target shared drives (not the root shared drive). Additionally, check that Map content only is turned on in the mapping.
Restricted permissions
Restricted permissions (where a child file or folder has fewer permissions than its parent) are not supported by shared drives. If the file or folder has restricted permissions on the source account, the restricted permissions are not migrated.
Access to shared drives on target account
If the original content authors don’t have access to the shared drives on the target account, files are transferred using the target GUser account specified in the mapping. This type of transfer can create bottlenecks and slow a migration. Make sure that you turn on the Migrate folder permissions setting in the settings template. Go to Migrate to shared drive. Add additional target GUser accounts to help distribute load. Use at least one target GUser account for each active node server.

Other types of data

Groups
For Google Groups, you must create groups in the target account first. Groups aren't automatically created by the migration process. When migrating groups: Use an identity mapping to map a group on the source account to an existing group on the target account. For details on what to specify in the mapping, go to Create & manage an identity mapping. It might take up to 24 hours to see new groups on the target account. Until then, you won't see them in the tree-view for a scoped view or mapping. Additionally, a mapping for a group could display as invalid.
Forms
When migrating forms: If the form doesn't have a linked response sheet, responses aren't migrated. If a response sheet is linked to a form, the association between the 2 is lost after a migration. You can restore the link manually. For details, go to Choose where to save form responses.

Next step

Now it's time to set up a Google Workspace connection. To get started, see Add a source connection.

_{Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.}