Watchpoints for Google to Google migrations

Google Workspace to Google Workspace migration

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, calendar, Google Drive items, 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.

↑ back to top

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 limit for the Calendar API:
  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 queries-per-minute quota of 160 times that amount. For details, go to Requesting a higher quota limit.
Use an identity mapping
To transfer calendar resources correctly, use an identity mapping. 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 Pre-built 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.
  • If you turn off the Use all super admins to write resource calendar events setting in the settings template, only the Google Workspace Migrate admin account is used to migrate calendar resources.

↑ back to top


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 and: 
  • 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 automatically 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 will restore 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.

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

From version, during a Google Workspace to Google Workspace migration, Google Workspace Migrate no longer creates orphaned Google Drive items on the target account. Later in 2022, this notice will apply to all versions of Google Workspace Migrate.

Google Workspace Migrate no longer creates orphaned Google Drive items on the target account if you:

  • Check the Orphaned content box for the source and target account when creating a mapping.
  • Use the GOrphanedContent mapping header for both the source and target accounts.

When orphaned content isn't created on the target account, orphaned items are migrated to the target owner's My Drive root. To avoid this scenario, you can:

  • Directly map orphaned content on the source account to a specified Drive folder on the target account. 
  • Use the Sub Path header in your mapping to migrate data to a new folder on the target account. For details, go to Scoped view & mapping headers.

↑ back to top

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 the Migrate folder permissions setting is turned on 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. 
Externally owned files shared with internal users
Files in shared drives that are owned by users outside of your organization can be migrated to the target account. Ownership is transferred to the internal user who first gets the migrated file.

Tip: Use the Shared content by user report to identify externally owned files. For details, go to Understand scan reports.

↑ back to top

Other types of data


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.
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. The link can be restored manually. For details, go to Choose where to save form responses.

↑ back to top

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.

Clear search
Close search
Google apps
Main menu
Search Help Center