Whether you’re navigating the complexities of mergers, acquisitions, or divestitures, the need to migrate between Google Workspace environments is more common than you might think.
On the surface, moving within the same ecosystem feels like it should be native. However, an enterprise-grade migration is rarely a “plug-and-play” project. Done right, it is a smooth, invisible transition for the end user; done without the correct tooling and a strict order of operations, it can lead to orphaned data, broken permissions, and significant downtime.
This guide walks you through the technical strategy required to plan and execute a successful Google-to-Google migration using CloudM Migrate.
Why Migrate Google to Google?
Organizations migrate between Google Workspace tenants for several strategic reasons:
- Mergers and Acquisitions: Bringing two organizations onto a single tenancy.
- Divestitures (Carve-outs): Separating a business unit into its own independent environment.
- Domain Changes: Moving to a new primary domain or rebranding.
- Tenant Consolidation: Streamlining multiple legacy Google environments into one.
Whatever the driver, the complexity adds up quickly when you factor in the “interconnectedness” of Gmail, Google Drive, Shared Drives, Google Groups, Calendar resources, Chat, and Spaces.
Choosing the Right Deployment: Hosted vs. Self-Hosted
The first technical decision is your deployment architecture:
- CloudM Migrate Hosted: Ideal for smaller, less complex projects. Your environment is set up automatically and tied to your license.
- CloudM Migrate Self-Hosted: Designed for larger, more complex projects. This provides maximum control over data residency and security.
- Scalability: Self-hosted is the recommended route for large migrations (25,000+ users or 10 million+ objects), as it allows for dedicated PostgreSQL and Redis servers to handle high-concurrency loads.
To help you make the decision, visit our Knowledge Base for more information.
Before You Begin: Key Pre-Migration Checks
A successful migration starts with protecting identity integrity. Before moving data, you must validate:
- Licensing: Ensure you have enough CloudM Migrate licenses and Google Workspace licenses in the destination.
- Supported Data Types: Confirm exactly which entities (Users, Groups, Drive, Chat, Spaces, Resource Calendars) are in scope. For more information, visit Supported Platforms, Entities, and Data Types.
- The Master Address Replacement CSV: This is the “brain” of your migration. You must maintain a master mapping of source-to-destination email addresses throughout the project to preserve Drive sharing permissions, Calendar attendees, and file ownership across batches. You can find out more about this here: Domain and Email Address Mapping in CloudM Migrate.
The Recommended Order of Operations
In a Google-to-Google scenario, sequencing is critical. If you move Drive data before establishing identities, permissions will not “stick”. Follow this recommended sequence:
- Create Migration Batches: Separate your project by entity type (Users, Groups, Resources, Shared Drives, and Spaces).
- Create Users in the Destination: Use CloudM’s Check User State feature.
- Initialize the Master Address Replacements CSV: Begin with user mappings and import the updated CSV to each batch as you proceed.
- Migrate Google Groups: CloudM Migrate creates the groups and populates members based on your replacements.
- Update the Master CSV: Add the newly created group addresses to your replacement list.
- Provision Resource Calendars: Create these in the destination and add their new addresses to the Master CSV.
- Update the Master CSV: Add the newly created resource calendar addresses to your replacement list and import the updated CSV to each batch.
-
Phased Migration Strategy
Once identities are established, begin your migration phases:- Phase 1: Bulk/Historical Data MigrationThis is the large-scale pass of the majority of historical data, typically recommended for Email and Drive. If any addresses change during this phase, ensure the Master Address Replacements CSV is updated and re-imported to all batches.
- Phase 2: Delta/Go-Live Migration (Post-Cutover) Immediately following the cutover, run a delta pass to capture new or changed data since the bulk pass. This includes Users, Email, Drive, Contacts, Calendar, Tasks, Chats, Resources, Shared Drives, and Spaces.
Entity-Specific Watchpoints
- Google Groups: These must be provisioned before Google Drive migrations. Without destination identities for groups, Drive permissions assigned to those groups will be lost. Check this guide for more information on this and the following point: Best Practice Guide: Google Drive to Google Drive Migrations.
- Google Drive (Subsets): Migrating a subset of users—common in divestitures—requires extra care to avoid “orphaning” shared files where the owner is not part of the move.
- Google Chat & Spaces: These require the Google Chat API to be enabled and configured specifically during the pre-migration phase.
- Resource Calendars: Consistent address replacements ensure that room bookings and equipment remain linked to the correct users and calendars in the new tenant.
Domain-Switch Migrations: A Special Case
If your project involves moving a primary domain from one tenant to another, standard workflows do not apply. This “switch” carries specific risks regarding mail flow and identity downtime, requiring a dedicated best-practice strategy.
A full best practice guide is available here.
Ready to Migrate?
A well-planned Google Workspace migration is defined by continuity, not crisis. By prioritizing logical sequencing and identity mapping, CloudM Migrate handles the technical heavy lifting so your team can focus on the business goals behind the move.
