Skip to main content
  1. CloudM
  2. Migrate
  3. Perform a Migration
  4. Common Migration Scenarios
  5. To Google Workspace
  6. From Google Workspace to Google Workspace

Best Practice Guide: Google Drive to Google Drive Migration for a Subset of Users

Updated

When performing a Google Workspace to Google Workspace migration for only a subset of your users, special considerations are required for Google Drive. CloudM Migrate provides specific configuration options to handle these scenarios, which are typically driven by organizational changes such as divestitures or mergers and acquisitions (M&A).

This guide outlines two distinct migration scenarios based on how you handle permissions for users who are not part of the migration. This guide is designed to be used in conjunction with our general Google Drive to Google Drive Migrations - Best Practices and Concepts article.

Initial Configuration: Shared Steps for Both Scenarios

These steps are a baseline for all subset Drive migrations. Complete them before proceeding to your chosen scenario.

Preparation

  • User Provisioning: Ensure all migrating users exist in the destination.
  • Group Provisioning: All groups and their members must be properly created or mapped in the destination, including those containing non-migrating users. This is critical, as groups define sharing and access permissions.

CloudM Migrate Batch Configuration

  • Items to migrate
    In the Items to migrate tab, list only the users you are migrating.
  • Source settings
    • Enable Configuration > Source > Document > Migrate items only from listed users.
    • This ensures CloudM Migrate only migrates files owned by the users in your list.
  • Destination Settings
    • Enable Configuration > Destination > Document > Allow alternate item ownership.
    • This setting allows folders owned by non-migrating users, which a migrating user has access to, to be transferred to the migrating user. This preserves their MyDrive folder structure.

Scenario 1: Maintaining Permissions for Non-Migrating Users

This strategy is for migrations where you must preserve all sharing permissions for both migrating and non-migrating users in the destination.

Specific Configuration

In addition to the Initial Configuration, you must configure the following:

  • Address Replacements CSV
    Use an Address Replacements CSV file to map the email addresses of all migrating users (and their aliases), all groups, and the migration domains.
  • Advanced settings
    • Non-matched address replacement behavior: Navigate to Configuration > Advanced settings > Address replacement and set Non-matched address replacement behaviour to Retain original.
    • This ensures permissions for non-migrating users are preserved with their original addresses.

Watchpoint: CloudM Migrate performs a copy operation

CloudM Migrate creates a new file in the destination rather than moving the original from the source. This means that throughout the migration, there are two separate files: the original source file and the new migrated file in the destination.

In this subset migration scenario, both migrating and non-migrating users will have access to both versions of the file.

To avoid data discrepancies and ensure a clean transition, we strongly recommend the following:

  • During the migration: The source file remains the source of truth. Do not touch the destination files until the entire migration is complete.
  • After the migration: The new file in the destination becomes the source of truth. We recommend removing access to the source files for all migrating users, or deleting the source users' accounts entirely, to prevent confusion and ensure everyone is working from the correct version.

Scenario 2: Not Maintaining Permissions for Non-Migrating Users

This strategy is for migrations where you do not need to preserve permissions for non-migrating users. Their permissions will not be carried over to the destination environment.

Specific Configuration

In addition to the Initial Configuration, you must configure the following:

  • Address Replacements: Create an Address Replacements CSV that contains domain replacements, migrating users, and groups. Ensure all source-to-destination domain pairs are included. If you have multiple source domains, you must manually ensure every domain maps to the destination, otherwise unmapped domain permissions will carry over.
  • Advanced Settings:
    • Non-matched address replacement behavior
      Navigate to Configuration > Advanced settings > Address replacement and set Non-matched address replacement behaviour to Replace domain.
    • Replace CSV addresses only
      Disable Configuration > Advanced settings > Address replacement > Replace CSV addresses only.
    • This is critical for achieving the required reject-and-drop behavior. Leaving this setting OFF ensures that a domain-level rewrite is forced on all unlisted, non-migrating user addresses.

Migration Behavior & Watchpoints

This configuration prevents CloudM Migrate from applying permissions for non-migrating users indirectly. By forcing a domain rewrite on their addresses during migration, the resulting user account does not exist in the destination. Because the account does not exist, Google rejects the share, and the permission is never applied.

Watchpoint: This method drops a permission only when the rewritten destination address does not exist. If a rewritten address happens to match an active account in the destination, the share will be applied to that account instead.

Workaround for Destination Username Conflicts:
If a non-migrating user shares a username prefix with an active, unrelated account at the destination (e.g., jsmith@source.com rewrites to an existing jsmith@destination.com), you must force a failure to drop the permission. To do this, explicitly map the non-migrating user in your Address Replacements CSV to a deliberately non-existent destination address.

  • Example Mapping: jsmith@source.com -> forcedfailure@destination.com

This explicit mapping overrides the standard domain rewrite, ensuring the API encounters a non-existent account and successfully rejects the share.

Additional Considerations

Username Conflicts

Username conflicts can occur if a user already exists at the destination domain with a username prefix that matches a source user's email address.

Example:

  • Source User: j.smith@source.com
  • Existing Destination User: j.smith@destination.com
  • Unrelated third-party user exists at the destination as j.smith@other.com.

To navigate this in Scenario 2 (since Replace CSV addresses only is disabled), you must ensure that all explicit user replacements are cleanly defined in your Address Replacements CSV file to avoid unintended matching.

Related Articles

Related to:

Was this article helpful?
0 out of 0 found this helpful