Monitoring points for Google to Google migrations

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.

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.

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.

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.

1. Run a scan to get the total number of events and users that you need to migrate.
2. Determine how many users you're likely to migrate at the same time.
3. Request a Calendar API QPM quota of 160 times that amount. For details, go to Requesting a higher quota limit.
4. Make sure that your per minute write operations don't exceed 60 QPM. The rate limit for write operations can't be increased.

• Transfer calendar resources
• Map an event organizer, when the organizer is external to your organization

For details, go to Create & manage an identity mapping.

To use content compliance rules to deliver these messages to email quarantines, go to Set up rules for advanced email content filtering.

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.

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.

• 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. 

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.

Emptying the trash avoids this issue and allows you to run a fresh migration.

• 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

• 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.

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.

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.

• 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.

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.

• 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.

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.

• 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.