Skip to main content

Google Workspace Domain-Switch Migrations with CloudM Migrate

This guide details the essential steps for performing Google Workspace domain-switch migrations, specifically when your source domain name is migrating to the destination. While CloudM Migrate efficiently handles standard Google Workspace migrations, transferring the primary domain introduces additional complexity. Following these instructions will help ensure a smooth migration with minimal disruption.

 

Important Note: Migration Strategy

This article outlines a specific migration strategy. It's crucial to integrate these steps with CloudM's recommended migration strategy. Thorough planning is paramount to minimize downtime. We strongly recommend reviewing this guide completely and planning all steps well in advance of your scheduled domain switch-over.

 


 

Understanding Domain-Switch Scenarios

There are two primary scenarios for Google Workspace migrations involving domain names:

 

Scenario 1: The Domain Name is NOT Migrating

 

If your source domain name(s) (e.g., source.com) are not being transferred to the destination Google Workspace instance (i.e., you're migrating to an entirely new, different domain name, e.g., destination.com), then the migration can be configured and performed using CloudM's standard migration procedures without any extra steps.

 

Scenario 2: The Domain Name IS Migrating (e.g., source.com will become the new primary domain at the destination)

 

This scenario is more complex due to a fundamental Google Workspace limitation: a domain cannot be simultaneously associated with two active Google Workspace instances. Therefore, a direct, same-domain migration in a single step is not possible. A phased approach is required:

  • An initial migration must first transfer users from the original source domain to a temporary destination domain (e.g., user@source.com to user@temp.destination.com).

  • Crucially, before the go-live cutover, the migrating domain (e.g., source.com) must be removed from the source Google Workspace and then added to the destination Google Workspace.

  • Finally, a delta migration is performed to capture any changes that occurred during the domain switch period.

 


 

Prerequisites

Before commencing a Google Workspace domain-switch migration, ensure the following prerequisites are met:

  • Destination Google Workspace Instance: A fully configured destination Google Workspace instance is required. It is strongly recommended to set up a temporary primary domain (e.g., temp.destination.com) for this instance.

  • CloudM Migrate License: Only one CloudM Migrate license is required for the entire migration project. This license should be assigned to your temporary destination domain (e.g., temp.destination.com) and remain active throughout the project.

    • Product Improvement: CloudM Migrate licenses are assigned to each destination user/item by ID. This means that when you update the Import Names for your items during the delta migration, an additional CloudM Migrate license will not be consumed.

  • Service Accounts: Both source and destination Google service accounts must be properly configured.

  • Temporary Source Secondary Domain: Another or temporary secondary domain (e.g., temp.source.com) is essential at the source Google Workspace instance. This domain will facilitate the domain switch later in the migration project.

 


 

Migration Steps

Follow these sequential steps to successfully perform a Google Workspace domain-switch migration:

 

Step 1: Configure CloudM Migrate for Initial Migration

  1. Configure your CloudM Migrate batch to migrate users from your source domain to your temporary destination domain.

    • Example: user1@source.com > user1@temp.destination.com

  2. Ensure that temp.destination.com is set as the licensed domain within CloudM Migrate. It must remain the licensed domain throughout the entire migration project.

    • Benefit: This approach allows for consistent licensing, a unified migration user interface (UI), and a continuous migration history across the entire project.

 

Step 2: Perform Initial Migration of Historic Data

  1. Execute the initial migration for all historic email, calendar, and Google Drive data.

  2. In your CloudM Migrate batch's Items list, ensure entries reflect the temporary destination domain:

    • Example: user1@source.com > user1@temp.destination.com

  3. Recommendation: It is highly recommended to migrate historic calendar data before proceeding with the subsequent domain switch steps. See here for more information.

 

Step 3: Prepare Source Domain for Switch-Over (Critical)

Important: These steps involve changes to your live Google Workspace domain and should be planned meticulously to minimize downtime.

  1. Change the Primary Domain at the Source: Change the primary domain of your source Google Workspace instance to a different domain (e.g., temp.source.com or another existing secondary domain).

    • Note: Review Google's prerequisites for changing your primary domain to avoid issues (e.g., ensuring no user or group uses the primary domain for an alias, no Google Sites are associated with it).

  2. Rename Source Users: Rename all migrating source users in Google Workspace to use the temporary or secondary domain (e.g., user1@source.com becomes user1@temp.source.com).

  3. Remove Alias Addresses: Remove all alias addresses associated with the original source domain (e.g., source.com) from all users.

    • Tip: GAM (Google Apps Manager) is a very useful third-party application for performing such bulk tasks that can be more challenging to manage directly within the Google Workspace Admin console.

  4. Remove Migrating Domain from Source: Once all users are renamed and aliases removed, remove the migrating domain (e.g., source.com) completely from your source Google Workspace instance.

    • Steps 2 and 3 above are imperative prerequisites to perform this action.

 

Step 4: Integrate Domain into Destination Google Workspace

  1. Add Domain to Destination: Add the migrating domain (e.g., source.com) to your destination Google Workspace instance. This can be added as a secondary or alias domain, depending on your specific needs and plans for the new environment.

    • Domain Relationship: The source.com domain is now removed from the source and added to the destination.

  2. Temporary Domain Retention: temp.destination.com should remain on the destination as a secondary domain. This is crucial as it allows your CloudM Migrate license to remain unchanged and valid throughout the project.

 

Step 5: Reconfigure CloudM Migrate for Delta Migration

  1. Rename Destination Users/Add Aliases: In your destination Google Workspace, rename your users to the new primary domain (e.g., user1@temp.destination.com becomes user1@source.com), or add source.com as their primary email alias if temp.destination.com will remain the primary.

  2. Update CloudM Migrate Batch Configuration:

    • Source Connection: Edit the Source Connection details. The 'Domain name' field and the 'Admin username' field must both be changed to reflect the new temporary source domain (e.g., temp.source.com).

    • Destination Connection: The Destination Connection generally does not need to be changed as the license is tied to temp.destination.com.

    • Items List: Your items list in the batch must be updated to reflect the user email changes made in the above steps:

      • Example: user1@temp.source.com > user1@source.com

    • Domain Replacement Values: Update your domain replacement values within CloudM Migrate:

      • Example: temp.source.com > source.com

    • Address Replacements CSV: If applicable, your address replacements CSV file also needs to be updated to reflect the new domain mappings.

 

Step 6: Run Delta Migration

Initiate the delta migration. This will transfer any mail, contacts, calendars, tasks, Drive data, and chats/Spaces that have changed or were created since the initial migration, using the newly configured domain mappings.

 

Step 7: Post-Migration Cleanup

  1. Source Google Workspace Deletion (Recommended Grace Period): Upon successful completion of the delta migration, the source Google Workspace instance can be deleted. However, we highly recommend allowing approximately a one-month grace period before doing so. This provides a buffer in case of unforeseen technical issues, unexpected behaviors, or the need for additional migrations.

  2. Temporary Domain Deletion: You may also choose to delete the temporary source and destination domains (e.g., temp.source.com and temp.destination.com) which were used solely for the migration project, once you are confident they are no longer needed.

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