Google Workspace to Google Workspace

Claude Morings Jr

Updated June 08, 2023 00:01

Google Workspace to Google Workspace

Before starting your migration project, make sure you have setup the Google Workspace tenants using the configuration guide. Be sure to validate both tenants have passed their connectivity tests with no errors.

TABLE OF CONTENTS

Standard Pre-stage Migration

There are multiple approaches available to migrating data with CloudM Migrate. The following approach will pre-stage email older than 30 days as a batch. This will be followed by a Delta Sync to migrate recent data after your DNS cutover for a complete lossless migration.

This approach eliminates user confusion from recent items being moved as they are created and categorized during normal business. The result will be a more accurate account of recent changes on the destination and less user support.

CloudM Migrate doesn’t duplicate emails or documents. Once an email is migrated it is not moved again or updated on the destination even if it has changed on the source. Documents are not duplicated, but may be overwritten in delta migrations.

Adding Users

On Step 3 on the left, select Add items to migrate for options on how to collect targeted items to migrate from Google. The following options will be available:

Get items from source - This is fetch where CloudM Migrate will attempt to list all supported items within scope.
Bulk add/import items - Provide CloudM Migrate a CSV of targeted items.
Add User - Add a specific user to the project.
Add Resource - Add a specific calendar resource to the project.
Add Shared Drive - Add a Shared Drive to the project.
Add Group - Add a Google Group to the project.

Scanning the Source

It’s recommended to perform a scan against your Google source environment to proactively look for problems. While in CloudM Migrate select Step 5 on the left and then select Start. Depending on the size of the environment this can take some time to complete. When complete select Export Scan Results to download a zip of the scan results.

The important files to check are the FileScanReport.html and MailScanReport.html. Users that have items errors are highlighted in red. Important errors to look for are:

Dead User Objects. Files owned by non-existent accounts.
External File Shares. Items CloudM Migrate cannot migrate as they are external to the environment.

Domain and Address Replacements

Note: Domains should always be mapped, but address replacements are optional and usually only need to be provided when you have specialist requirements. CloudM Migrate maps usernames and email addresses automatically if they have been configured in the user list however if you need to map unlisted users you can add them to the Address Replacements File.

There are a number of options which control how replacements are performed. It is important to understand how these applied, in which order and under which conditions. It is possible to end up with incorrect email addresses if the options are not fully understood.

Replace Usernames – Replace any re-mapped usernames from the users tab, when migrating the items specified in Domain Replacement Types in Common settings. If this option is disabled and replacements are required, explicit mappings for email addresses and domain names should be provided via the other settings in this section. Only addresses that belong to source domains are automatically mapped. When migrating from Google Workspace, the source domains are automatically identified, but when migrating from other sources you should specify the domains in the next setting: Address Domain Replacements

Address Domain Replacements - If migrating from one domain name to another, specify the domain names that should be replaced and the value with which they should be replaced with. For example, when migrating from example.com to domain.com, you should provide example.com and domain.com in this setting. If migrating from one Google Workspace domain to another, domain replacements are performed automatically unless Replace CSV Addresses Only is selected and you have not provided the domain mappings within the file.

Address Replacements (File) – Use this option to provide an explicit list of email addresses to be mapped as part of a migration. If performing domain consolidation or if you have other specialized requirements then this option can be used to map any source email address to any other address. Addresses should be mapped using a simple CSV file containing two columns, the first for the address to be replaced and the second the replacement address.

Migrating Secondary Calendars

In a Google to Google domain-switch migration, where the primary source domain is being moved to the Google Workspace destination, calendars should be migrated before the source domain is deleted. This is because when the domain is removed from the source secondary calendars are deleted and cannot be recovered.

As migrated calendar events cannot be changed/updated, it is recommended to carry out a full calendar migration shortly before carrying out the domain switch to ensure you migrate the most recent version of users’ primary and/or secondary calendars.

Google Drive Watchpoints and Best Practices

Due to the flexibility of how files and folders can be organized within Google Drive, CloudM Migrate has to perform Google Drive migrations in a specific way to maintain integrity in the destination Drive. CloudM Migrate has been implemented to provide extremely high integrity and fidelity during a Google Drive migration. All folder structures, included shared folder structures, file locations, item starring and modification dates are preserved during a migration.

There are a few things to be aware of when performing a Google Drive migration:

Provision all Users and Groups Before Migration

Provision all of your users and groups before performing a Drive migration. This is required to ensure all sharing and Drive hierarchies are preserved correctly during the migration.

You should ensure all of your Drive users have Drive enabled in the destination.

Usage of the destination drive during a migration is not recommended. Items may not be moved into place for all users until the full migration for all users has completed. If items are moved around in the destination domain during a migration multiple problems can occur with migration and may cause migration times to increase significantly.

If you are renaming users as part of the migration, you must make sure all import and export names are present and have been updated to the names in the new system. You should ensure you have provisioned all of your users before migrating your groups and do not rename groups during a migration. Renaming Groups must be done before the migration begins.

Migrate Items Only From Listed Users

This option will migrate only Drive files from those users listed on the Users tab. Set Migrate All Drive Items to true for this setting to work. If you want to migrate items from users other than those being migrated add them to the user tab but do not select them for migration.

Migrate Items Only from Listed Users

This should be used with care and only ever used if you are only migrating a subset of your users. If you are migrating all of your users during a migration, you should not select this option for any part of your migration. If you do use the option, you should ensure that your user list is fully correct before starting the first migration.

Migrate Contents of Non-Owned Folders

Migrate files from folders not owned by the migrating users. This usually only needs enabling when some users are not migrated but the Drive items need to be migrated. Folders will always be processed. This option should not be used in conjunction with Migrate Items Only From Listed Users.

Files and Folders May be Migrated for Other Users

During a migration of the migrating user, files and folders that were shared with the migrating user may be migrated for the owning users, even when they are not being migrated at that time. This is essential to preserve the complex structure of Google Drive. It is possible to disable this action by setting the option Migrate All Drive Items to False, but it is highly recommended to use the default behavior to preserve Drive integrity.

Files from Outside of the Domain

Only files owned by users inside your domain are migrated. While it may be possible to migrate files from outside of the domain where the user has edit access, this involves making changes to files outside of the migrating domain which raises many security issues for the external domains and is therefore not enabled.

Folder Hierarchies from Outside of the Domain

It is possible to add folders that have been shared with you into your folder hierarchy, and other users could also have done the same thing. If this is a folder from outside of your domain, then the first user to migrate the folder will become the new owner and it will then be treated as belonging to that user. All external ACLs will be removed from the folder but all domain ACLs will be preserved.

Comments and Revision History

Comments can be migrated but revision history cannot.

Deleted Files and Folders

Deleted files and folders a user owns are not migrated.

If a user has deleted a file that has been shared with them making the file invisible in their account but have not actually deleted the source file or the sharing rights, then these files will be visible again in the Shared with me folder following the migration. This particular case is not handled by CloudM Migrate as its usage is rare, and when encountered increases migration times. Additionally, even though the file may be invisible, the sharing rights as allocated by the sharer still exist.

Renaming Users and/or Groups

CloudM Migrate has functionality to allow user or group email addresses to be changed or mapped during a migration. This is achieved via address replacements.

Shortcuts

Google Workspace now uses Drive Shortcuts to allow you to share access to a document or item with multiple people. This means that, instead of each person having their own local copy, they are able to use a shortcut to the location of the original document or item, as long as they have permission. The benefits of using Drive Shortcuts include increasing team collaboration and freeing up storage space as a shortcut takes up a fraction of the storage space compared to a local copy.

When migrating items from a Google Workspace domain to another Google Workspace domain, CloudM Migrate also migrates a user’s Drive Shortcuts. These Drive Shortcuts will be counted as an “item” in the Environment Scan, but can be filtered in the CSV by the mimetype to get a true count if required.

Here are a few scenarios where a shortcut file will not be migrated:

If the target file for the shortcut has been deleted, and either exists in or has been purged from the Deleted Bin, the shortcut will not be migrated. Both will be logged as export failures in the reporting.
If the target file exists in the Deleted Bin, the error message will read Shortcut target file <target file name>, <target fileID> has been trashed, skip export of the shortcut file.
If the target file has been deleted and then purged, the error message will read Shortcut target file with id: <target fileID> could not be found, skip export of the shortcut file.
If the target file exists in a different drive, the shortcut will not be migrated. In this case, a different drive means a shared drive target file if the shortcut exists in a user drive, and a different shared drive target file if the shortcut exists in a shared drive.
If the target file exists in a different drive, the error message will read Migration of shortcut files pointing to files in different drives is not supported.
The shortcuts for externally owned target files that have not been shared with the account being migrated will not be migrated. Additionally, if the destination user is unable to see the external target file, the shortcut will not be migrated.
Changing the owner of a target file before delta migration will only change the owner of the target file on the destination. The shortcut file owner will not change.
When a target file is migrated to any destination platform other than Google Workspace or Google Cloud Storage, the shortcut will not be exported. In the trace file, you will see the following message - <Migration of shortcut file is not supported for this platform. File name: 'target file name'>

Migrating a subset of users

When performing a Google Workspace to Google Workspace migration and only a subset of the total source user base is migrating in a batch there are special considerations when including Google Drive.

Always provision all of your users and groups before performing a Google Drive to Google Drive migration in batches. This is required to ensure all sharing and Drive hierarchies are preserved correctly thoughout the full migration.
Validate that all migrating users exist in the destination.
Validate that all groups and members are created or are mapped in the destination, also.
Configure an Address Replacements CSV.
Enable ‘Address Replacements’ / Replace CSV Addresses Only.
Enable ‘Migrate Items Only From Listed Users’ in the source Google Workspace settings.
In Users, Get Users and then remove the non-migrating users or import a CSV list of all migrating users.
Migrate.

If you do not wish to maintain permissions for users who are not migrating, prepare and configure the migration using the default CloudM Migrate settings for Drive and list only migrating users in the user list and Address Replacements. When migrating Drive, any folders owned by non-migrating users will be migrated. Ownership will be changed to the migrating user and any explicit file and folder permissions will attempt to be replaced because the destination address does not exist. All migrating user permissions will be applied.

Note: If migrating into a Google Workspace domain with existing users, conflicting addresses should be considered. If users exist at the destination domain with prefixes of existing source users, the replacements may cause items to be shared with those users. To avoid this, enable Replace CSV Addresses Only and list only migrating users in the Address Replacements CSV file.

Shared Drives

CloudM Migrate supports the following migration scenarios for Shared Drives:

Migration from Shared Drives to Google Drive Users for different domains
Migration from Google Drive to Shared Drives for different domains
Migration from Shared Drives to Shared Drives for different domains
Migration from Google Drive to Shared Drives within the same domain

Requirements:

External sharing or whitelisting of the destination domain(s) on the source is required. This is set three different ways: by the domain-wide Google Drive setting, by the shared drive setting (below the prior) and by the shared drives own settings. External (destination domain) users need to be able to be added to the source shared drives and access the files in order to perform the migration.
Ensure that the “Prevent non-members of the shared drive from accessing files in the shared drive” setting is set to disabled.
Your Google Workspace domain must have Shared Drives enabled. This is part of your contract with Google, if you do not have Shared Drives enabled contact Google or your reseller.
Existing Shared Drives need to have at least one user with Manager permissions applied. If you use CloudM Migrate to create Shared Drives, however, the migration admin will become a Manager.
Managers must be an active user, not suspended and not a group, and have Drive enabled.
Source Shared Drives must include at least one user, not group, that has ‘Manager’ permission set on the Shared Drive.

Note: You must specify the ID or name of the Shared Drive in Export Name when migrating from Shared Drives, and the ID or name of the Shared Drive in Import Name when migrating to Shared Drives.

To improve performance to Shared Drives, configure multiple Managers to perform the migration with the configuration setting Shared Drive Default Managers.

Google Groups

When using Get Items from source, groups will be populated in the user list along with users, shared drives and calendar resources. When selected for migration, CloudM Migrate will create the Groups in the destination with the specified Import Name. It will add the members and their membership status (member / manager / owner) will be applied. Subsequent migrations will add new members if they are added on the source. Member deletions and changes to member statuses are not applied. Alternatively, objects including Groups can be imported via CSV file.

It’s important to check if there are existing groups in the destination Google Workspace instance. Any groups that are listed from the source could potentially have equivalent groups in the destination, so renaming the migrating groups import names in your items list, to create new ones and/or to distinguish them from the destination groups, would be advised. If you are renaming groups import names, these changes will need to be reflected in an address replacements CSV file.

Note: Google Group settings and content are not migrated, only the group itself and its membership.

Batching

CloudM Migrate allows you to create a batch from your master user list, in a separate configuration. This enables you to quickly segment your user list and streamlines your migration process by running batches of users.

Select the users you want in your migration batch.
From the menu, select Create Batch.
Name your Child Configuration.
Select your configuration type.
- Disable Migration Items - Use this if you want to modify the migration items for a subset of your users. e,g. Do not migrate Drive.
- Delete Migration Items - Use this if you want to create a subset of users to migrate. e.g. a VIP group of users.
Select Create to create the batch, or Create and Edit or create the batch, and be taken to the edit screen for that batch. Batches can be modified from the Projects screen, and work in the same way as normal configuration.

Date Ranges for the First Batch

Select Step 4 and validate the source and destination domains are correct. Change the dates on the right set of columns to be 30 days before the current date.

Cutover

Once the first batch is completed a DNS cutover can be scheduled including moving the vanity domain. After a successful and validated cutover the Delta Sync can be started to sync all recent data.

It’s recommended to use the longest stretch of off-peak hours available. This will greatly speed up the Delta Sync as less new mail is inbound and throttling is reduced.

Delta Sync

Return to Step 4 change the date listed in the right set of columns to a future date - note all calendar events up to the selected date will be migrated. For recurring events the first event in the series must be within the date range selected for the entire series to be migrated.

Start the migration.

Statistics and Summary

After starting the migration, you’ll have the option to view progress and export a summary by selecting Start and then selecting View Progress. Select More Statistics to see a complete summary by item type for your current batch.

To export a report of the migration for record keeping select Projects in the left navigation. Select Item Progress and then select the orange User progress link. By selecting the top and right most orange button a file of item success by user can be downloaded.

Vanity Domain Switch

Google Workspace domain-switch migrations can be performed in the same way as other Google Workspace migrations, however, if the source domain name is being migrated to the destination this adds an additional layer of complexity relating to the domain name registration and CloudM Migrate licensing. This guide explains how to perform such migrations without running into issues. It is very important to plan ahead to minimize downtime during this process, so we recommend this guide is reviewed thoroughly and all steps planned well in advance of a switch-over.

If the source domain name(s) are not being migrated, then the migration can be configured and performed without any extra steps.

Because Google does not allow a domain to be associated with two instances at the same time. This means an initial migration must be performed to users with a temporary domain, then the domain must be deleted at the source and added to the destination before a delta migration is performed.

Configure CloudM Migrate to migrate from your source domain to your temporary destination domain.
Migrate all historic email and Google Drive data, whatever is applicable.
Rename all the migrated source users to another, either a sub-domain or temporary domain.
Change the primary domain at the source.
Delete the original primary domain from the source per this guide.
Add the new domain to the destination instance as a secondary domain.
Add that domain to all new migrating destination users as aliases.
Update your CloudM Migrate config to migrate from the new primary domain to the temporary destination domain.
Run the delta migration for email and Google Drive.
Rename the users in the destination from the temporary domain to the new domain.
Create a new CloudM MIgrate project/configuration to then migrate contacts, calendars/resources and tasks if applicable.
Change the primary domain on the destination.
Finally, you may need to perform a cleanup by removing the temporary destination domain/associated aliases.

Note: Changing the primary domain is not available for: Google Workspace Free edition, Google Workspace or Cloud Identity accounts in a trial period, Google Workspace or Cloud Identity accounts that included the purchase of your domain, Google Workspace accounts purchased through Google Domains, Google Workspace Resellers Licensing

CloudM Migrate licenses are assigned to each destination domain. This means that when performing the delta migration, after renaming the accounts, it will require another CloudM Migrate license. If you are running such a migration, you should contact us through your account manager or via sales@cloudm.io and we will be able to provide additional licenses to mitigate this at no extra cost.

Migration Enhancement Features

CloudM Migrate has several feature to enhance the migration, these can be configure before migrating based on desired results or to fit requirements.

Moving Attachments to MyDrive

There are several features for manipulating attachments while migrations are inflight. This includes removing attachments from the emails and replacing them with MyDrive links to the former attachments. Migrated documents can also optionally be shared with the recipients of the original email. This can dramatically shrink mailboxes on the destination.

Unsupported Data Types for Migration

Mail: Spam label
Mail: Categories
Mail: Filters
Mail: Settings
Groups: Messages
Groups: Settings
Calendar: Subscriptions
Calendar: Settings
Calendar: Appointment Slots
Contatcs: Directory
Contacts: Fields
Drive: File/folder creation date (will be reset to the date the file was migrated)
Drive: Shared with data (will be reset to the date the file was migrated)
Drive: Trash/Deleted Items
Drive: Revision history of Google format files
Drive: Externally owned files
Drive: Google My Maps
Drive: (New) Google Sites
Drive: Google Data Studio
Drive: Any third party shortcuts added using “Connect more apps”

Note: Google Forms and the answers gsheets are supported, but the links will be broken as they will have new URLs in the destination. You can use Document Mappings to determine what the new links are to fix that post-migration.