Google Workspace to Google Workspace Migration Watchpoints

This section details how email-specific settings and features are handled, including fidelity changes imposed by Google's API limitations.

Understanding the 'Migrated all Mail' Label

When migrating from Gmail or Google Vault, you may see a label named 'Migrated all Mail' appear in the destination mailbox. This is a system-applied safety net to ensure all mail is accounted for.

Application Conditions

This label is applied only if a message meets all of the following criteria in the source:

• Folder Status: The email is not in a standard system folder (Inbox, Sent, Drafts, Trash, Spam).
• Message Type: It is not a Chat message. (Note: Hangouts has since been deprecated by Google, but this often remains a point of confusion).
• Label Status: It has no user-defined labels applied.

Summary: This label captures "archived" mail that exists only in "All Mail" without any other organization.

Data Fidelity & Message Changes

• Message Size Limits (50MB): If a source message exceeds Google's 50MB limit (body + attachments), CloudM Migrate will strip the attachments and replace them with an empty text file named .removed to allow the message body to migrate. If the body itself exceeds 50MB, it is removed and replaced with explanatory text.
• Executable Files: Google blocks .exe and other executable files. If found in attachments (even inside Zip files), CloudM will rename them (e.g., appending .renamed) to force the migration.
• Received Headers: Google overwrites the 'Received' header with the date/time of the migration. This is a Google API behavior that cannot be overridden and may affect the sorting order in some email clients if they do not sort by the 'Date' header.

General Email Settings

• Settings & Customizations: Canned responses, filters, and mailbox customizations/themes are not migrated. Recommendation: Users must reconfigure these manually. Existing email filters can be exported from the original email account as an XML file and then imported into the new destination account under "Filters and Blocked Addresses".
• Signatures: Signatures and Out-of-Office replies migrate as plain text. Images in signatures do not migrate. Recommendation: The end-user is responsible for recreating any formatting (e.g., re-embedding images or logos) after migration.
• Snoozed Emails: Snoozed emails are migrated to the Inbox/All Mail, but the "Snooze" status and rule are lost. They will not automatically reappear at a set time. Recommendation: End-users should replicate any snoozed email rules manually post-migration.

This section details how file attributes, ownership, and permissions are handled during migration.

Externally Owned Data

• Behavior: CloudM Migrate is unable to migrate documents owned by external users due to the lack of access to external Google Workspace instances. It is important to note, however, that any documents owned internally with external sharing permissions will maintain those permissions.
• Recommendation: Any documents owned by external users will need to be re-shared back to the migrating users after Go-Live.

Orphaned Files and Folders

• Behavior: Orphaned files (those that no longer have an active owner or clear hierarchical path) will be migrated into a new folder named ‘Orphaned Documents’, created by CloudM Migrate. (Note: The behavior of orphaned folders is currently being verified).
• Recommendations
  • Audit Ownership Scope: Identify files owned by non-migrating, external, or deactivated users. If these owners aren't in the migration scope, reassign the items to a migrating "Data Custodian" in the source to preserve their folder paths.
  • Fix Nested Deletions: Locate files that are technically "active" but sit inside a deleted parent folder. These "pathless" items will be caught by the orphan logic unless they are manually re-homed before the cutover.
  • Post-Migration Triage: Monitor the size of the ‘Orphaned Documents’ folder post-cutover. A high item count typically signals an oversight in the initial user scope or a failure in the pre-migration reassignment process.

Deleted Files That Were "Shared with Me"

• Behavior: If a user deletes a file that has been shared with them (causing the file to become invisible in their account without actually deleting the source file or sharing rights), these files will reappear in the "Shared with me" folder after migration.
• Recommendation: The "Shared with me" section dynamically displays all files and folders shared with you by others, so it may contain a large amount of content. If an end-user wishes to locate a particular file, they will need to search within this section.

Document Version History

• Behavior: Migration of document revision history from Google Workspace to Google Workspace is not currently supported. Only the latest version is migrated.
• Recommendation: Prior versions should be generated or crucial information copied manually before the migration if deemed necessary, as users will not have the capability to undo modifications made before the Go-Live date.

File Metadata

During migration, CloudM Migrate handles file timestamps as follows:

Linked Files (Hyperlinks)

• Behavior: Hyperlinks to other Google files will become outdated because files are assigned new URLs in the destination.
• Impacts:
  • Embedded Links: Embedded files, charts, and references within documents will still point to the original file on the source domain.
  • External Applications: External apps (such as Slack) will still refer to older versions of documents from the original source.
  • Google Forms: Google Forms will no longer be connected to their response sheets.
• Recommendation: Use the CloudM Migrate Record Document Mappings feature to remap those links post-migration to the new IDs. Migrated users will be required to manually update hyperlinks.

Bin (Trash) & Starred Items

• Bin (Trash): Items located in the "Bin" (Trash) will not be migrated. If a user requires items from their "Bin" to be migrated, these should be restored to an active folder prior to the migration.
• Starred Items: "Star" status is not retained. End-users must manually re-star important files and folders post-migration.

Recent View

Behavior: End-users may observe alterations in the "Recent" view of their My Drive, where files may no longer be displayed in the correct sequence. This is anticipated, as the migration tool necessitates accessing documents to migrate them, triggering their appearance in this section.

File Comments

See: Migrating Google Drive Comments

• Behavior: Comments will be migrated by the document owner "On Behalf Of" the original commenters. Users will be notified via email regarding documents on which they have previously provided comments or been mentioned during the migration process. Recommendation: Notify end-users to expect these comment notifications to avoid confusion.
• Shared Drives: If comments are located within a Shared Drive, they will be attributed to the CloudM migration admin account rather than the user.

Shared Drive Settings, Limits & File Creation Limits

• External Sharing: To successfully migrate Shared Drives, it is necessary to enable external sharing on the source Shared Drive via the Google Admin console prior to migration.
• Membership: A "Default Organizer" must be included in the destination members list for each Shared Drive being migrated. If this user should not be present permanently, remove them post-migration.
• Limits & Metadata Queuing: Be aware of Google's 400,000 item limit per Shared Drive and 750GB daily upload limit per user. Crucially, during large migrations, if a single user attempts to create more than 500,000 items (files/folders/shortcuts) at the destination, file metadata becomes queued. This can lead to duplication if the migration is re-run before metadata is fully applied.
• Recommendation: Split large workloads into separate batches with different admin usernames specified as additional "Shared drive default managers" to bypass the daily upload limits and prevent metadata queuing errors.

This section details specific behaviors and critical workarounds for migrating calendar data within Google Workspace.

General Calendar Event Migration

• Event Ownership: The migrated account gains full ownership of the event, retaining the same level of control as they had in the source calendar.
• Attendee Notifications: Both internal and external attendees (with the exception of gmail.com accounts) will be notified of any changes made to a migrated event. Depending on their calendar platform, their event may also be automatically updated.

External Attendee Invitations (Critical Behavior)

Behavior: When calendar events are migrated, attendees who are external to your organization (such as partners using Google Workspace or Microsoft 365) will not receive a new calendar invitation for the migrated event. The event will be migrated to the internal user's destination calendar, but the external attendee's calendar will still hold the original invitation from the source account.

Why this happens: CloudM Migrate utilizes the Google Calendar Events: import method. This is designed specifically to prevent notification spam during a migration and does not send invitations. In other cases where events are modified, we intentionally suppress notifications to avoid flooding user inboxes and creating confusion. Using alternative methods (like Events: insert) is not suitable as it introduces a significant risk of creating duplicate events.

A notable behavior occurs if a destination user manually edits a migrated event and chooses to send updates to attendees:

• External attendees on Microsoft 365: Will correctly receive the updated invitation.
• External attendees on Google Workspace: Will not receive the updated invitation, even if you explicitly check "Send updates to guests" when saving the event. Their calendars remain tied to the original source event.

Recommendations: Due to this API behavior, we advise the following:

• Communicate with End-Users: Before the migration, inform users that they will need to manually manage calendar events that include external Google Workspace attendees.
• Manual Event Updates (The Workaround): Because editing the event does not push updates to external Google Workspace guests, the destination organizer will need to manually remove and re-add those specific external Google Workspace guests to the calendar event post-migration. This will force Google to issue a brand new invitation from the new destination account, successfully overriding the source event.

Recurring Appointments

For detailed information regarding supported scenarios, known limitations, and the required "Clean Slate" procedure for recurring events, please see the following article: Migrating Recurring Calendar Events: Supported Scenarios and Limitations.

Google Meet Links

Behavior: Meet hyperlinks will not migrate and require manual recreation for all host events. External users will not see the newly created Meet link automatically.

Recommendation: Substitute the Meet link by editing the event, removing the source Meet link, saving, and then re-editing to insert the new destination link. Re-send invitations to external participants to ensure their calendars update.

Secondary and Shared Calendars

• Behavior: Secondary or shared calendars migrate only if the owner is identified. CloudM does not automatically pin migrated secondary calendars to users' sidebars.
• Recommendation: Enable Send calendar sharing notifications in Configuration > Advanced settings > Calendar to provide shared users with an email link to add the calendar.

Calendar Sharing Notifications

• Behavior: Users receive standard notifications during the sharing process; these should be disregarded.

Appointment Attachments

• Behavior: Not migrated by default. Enable via Advanced Settings > Calendar > Migrate Attachments. Files transfer to the user's My Drive.

My Contacts vs. Other Contacts

• Behavior: 'Other Contacts' migrate into the 'My Contacts' section.
• Note: No action required. This ensures address auto-complete suggestions function as expected in the destination.

Chat Space Finalization (Critical)

• Import Mode (90-Day Limit): Spaces migrate in "Import Mode" to preserve timestamps. This expires after 90 days. If not finalized, Google will delete the destination space.

Formatting & Features

• Formatting Limitations: Trailing/leading spaces around bold text may cause bolding to fail at the destination.

• Google Sites: Not supported.
• Google Keep: Not migrated (use Google Takeout).
• Third-Party Apps & SSO: Play Store/Chrome Web Store purchasers and re-authentication.