Google Workspace Domain Switch: How to Migrate GWS Tenants When Your Domain Name Is Moving Too

What’s Special About a Google Workspace Domain Switch?

In a standard Google Workspace to Google Workspace migration, the source domain stays put. A domain-switch migration is different: the domain name itself transfers from one tenant to the other.

Google doesn’t allow a domain to exist in two active Workspace instances simultaneously. That means you can’t simply move the domain while users are live. Instead, you need a phased approach that temporarily re-homes identities, releases the domain at precisely the right moment, and renames users to their final addresses.

If this is your situation (i.e. source.com is leaving its current Workspace environment and joining a new one as the primary domain), you’ll need the steps below. If you’re simply moving to a completely new domain name, CloudM’s standard migration strategy applies instead.

What You Need Before You Start

• A destination Workspace instance built around a temporary domain (e.g. temp.destination.com) that serves as a staging environment.
• Confirmation of the number of CloudM Migrate licences required, as Google Workspace domain switch migrations do not require additional licenses for name changes or delta runs. See this Knowledge base article for more information on how Migrate licenses are consumed. 
• Configured service accounts with API access on both tenants. See CloudM’s service account setup guide.
• A temporary secondary domain at the source (e.g. temp.source.com) to allow users to be renamed off the primary domain before it can be released.

The Migration in Six Steps

1. Run your initial bulk migration: Migrate users from source.com to temp.destination.com. This is the heavy lift to get the majority of data across before the cutover window opens. 
2. Rename users at the source: Move all users off source.com onto your temporary secondary domain. For large organisations, do this with GAM (Google Apps Manager) rather than the Admin Console as bulk renames via the UI are slow and error-prone during a cutover window. Important: Ensure to include the removal of aliases and groups that reference the domain. If a single alias is missed, the next step will fail with a “Domain in use” error.
3. Release and add the domain: Remove source.com from the source tenant (demoting it from primary to secondary first if needed — see Google’s guidance here), then add and verify it at the destination.
4. Rename users to their final addresses: With source.com live at the destination, rename users from temp.destination.com to their permanent source.com addresses.
5. Update MX records and run your final delta: Update MX records so that new inbound mail routes to the destination, then run a final delta migration to capture anything that arrived at the source during the cutover window. CloudM’s migration history database ensures unchanged data isn’t re-migrated.
6. Decommission the source, but wait a month: Once the delta is complete, the source tenant can be deleted. Allow a one-month grace period first, as post-migration queries and edge cases are common, and having the source available is a valuable safety net.

The Risks That Catch Teams Out

• Bulk rename errors: Manual renames at scale during a live cutover window create real risk. Use GAM.
• Alias and group complexity: Every alias, group, and shared resource referencing the source domain needs to be accounted for in your address replacements.

Not Sure Where to Start?

Domain-switch migrations reward preparation and punish improvisation. CloudM’s pre-migration scan analyses your source environment upfront, flagging data volumes, permissions complexity, and potential issues before you commit to a timeline.

Talk to a CloudM migration specialist or explore the full domain-switch migration guide in our knowledge base.