A Google Workspace domain migration moves users, data and services from one Workspace environment to another. It rarely fails loudly. The job reports “complete,” and only weeks later does someone notice a file with the wrong owner, a Shared Drive that lost half its members, or a folder that never actually belonged to the company in the first place.
The way to avoid that is to audit the source environment before anything moves, map every identity and permission to its destination, pilot with a representative group of users, and validate the result against a baseline you documented up front.
This guide walks through each stage. For the full framework, see our Google Workspace domain migration guide.
A Google Workspace migration can complete successfully and still leave problems behind.
Users arrive in the destination, but the access model they relied on doesn’t always come with them. Files stay tied to owners nobody meant to keep. Shared Drive memberships need attention nobody planned for. Group-based permissions depend on identities that changed along the way. And business files that were shared into the domain from external accounts can sit outside the migration plan entirely, quietly, until someone goes looking for them.
For Google Workspace administrators, that means the migration shouldn’t begin with moving data. It should begin with understanding the environment you’re about to move: what exists, who owns it, who can access it, and which relationships need to survive the trip.
That’s the approach behind our Domain Migration solution: audit first, move second.
What is a Google Workspace domain migration?
A Google Workspace domain migration moves or reorganizes users, data, and services from one Google Workspace environment to another.
Organizations usually need one after a merger or acquisition, a divestiture, a company reorganization, or the consolidation of multiple Workspace environments into one.
It’s a different problem from leaving Google altogether. If you’re weighing a Google Workspace to Microsoft 365 migration instead, the platform changes, but the underlying discipline doesn’t: audit before you move.
Depending on the method and scope, a migration can touch:
Users • Gmail • My Drive • Shared Drives • Groups • Calendar • Permissions • External sharing • Organizational structure
There is no single approach that fits every scenario.
Google also offers Domain Transfer, a Professional Services offering built for merging Workspace environments. Eligible entities are moved rather than copied, which can preserve document IDs, URLs and permissions, but it comes with specific requirements and limitations.
So the first question an Admin should ask isn’t: “How do we move the data?”
It’s simpler and harder at once: What exactly are we moving, and what needs to remain true when it arrives?
Why Google Workspace migrations are more complicated than moving files
A Workspace environment is a network of relationships, not a pile of files.
Take one Google Drive file.
It has an owner. It may carry direct permissions. A Google Group might be the reason someone can open it. It could live inside a Shared Drive, be shared with external collaborators, or even be owned by someone outside your organization entirely.
Moving that file is only one part of preserving how it actually works.
Google’s own migration tooling reflects this. Google Workspace Migrate relies on identity mappings to connect source identities with destination identities.
In practice, the chain that matters looks something like this: Identity → Group → Permission → File → Shared Drive → External collaborator
Break one link, and access can change with it. So don’t define success as: “The data moved.”
Define it as: The right data moved to the right place, with the ownership and access model you actually intended.
What should you audit before a Google Workspace migration?
Before deciding how to migrate, build a baseline of the source environment.
That baseline gives you something concrete to plan against and, later, something to compare the destination to.
Manual spot-checks in the Admin console won’t get you there at scale, which is where domain-wide auditing does the heavy lifting.
1. Users and organizational structure
Start with the accounts that make up the environment:
- – Active users
- – Suspended users
- – Inactive accounts
- – Admin accounts
- – Organizational units
- – User attributes
- – Licensing
- – Accounts that shouldn’t move
Don’t assume the source OU structure should simply be recreated.
A migration is also a chance to ask whether that structure still reflects how the organization actually works today.
If departments, regions, policies, or responsibilities have changed, blindly recreating the old structure can carry years of administrative debt straight into the new environment.
2. Google Drive ownership
Knowing how much Drive data you have is useful. Knowing who owns it matters more.
Before migration, look at what’s owned by active users and whether their destination identities are already mapped.
Look at what’s owned by suspended or former employees and decide who should hold that business data afterward.
Look at what’s owned by external accounts, because the organization may not actually control that content the way it appears to.
And look for business files sitting under personal Gmail accounts, since that’s often where ownership quietly goes unmanaged.
An inventory based only on what users can see in Drive will give you a false sense of completeness.
A file showing up in someone’s Drive doesn’t mean your organization owns it.
That distinction decides what can simply move, what needs an ownership change, and what needs a different approach altogether.
Our Google Drive auditing reporting is built to surface ownership, sharing, and storage in one view rather than scattered across individual Drive accounts.
3. Shared Drives
Shared Drives need their own migration workstream.
Review: Content → Members → Roles → External members → Restrictions
Look for Shared Drives nobody uses anymore, managers who shouldn’t have that role, external memberships that have outlived their purpose, and access structures that no longer match how the organization operates.
The question isn’t: “Did the Shared Drive migrate?”
It’s: Does the destination Shared Drive have the right content, the right members, the right roles and the right restrictions?
That’s a much higher bar.
4. External and public sharing
A migration can just as easily reproduce a permission that should have been removed years ago.
Before moving anything, identify:
- – Files shared outside the organization
- – Public or link-based sharing
- – External domains with meaningful access
- – Former collaborators who still have permissions
- – Sensitive content exposed externally
- – Access inherited through Groups or Shared Drives
This is your opportunity to separate access that genuinely needs to be preserved from access that should never follow the data into the new environment.
What happens to Google Drive permissions during migration?
There isn’t one universal answer because it depends on the migration method and how identities are mapped.
Permissions can reference individual users, Google Groups, domains, Shared Drive members or external identities.
When identities change between environments, each of those references needs to be understood on its own.
That’s why permissions deserve to be treated as their own migration workstream, rather than a box to check afterward.
For every major dataset, map: Source identity → Current access → Destination identity → Required access
Then decide deliberately whether that access should be:
Preserved • Changed • Removed • Recreated
That gives the migration team a defined target instead of leaving it to whatever happens to arrive.
What about externally owned and shared-in files?
Employees often work with files the organization doesn’t actually own. They may belong to a supplier, former employee, another Workspace domain, or even a personal @gmail.com account. To the employee, they’re simply part of their work, but during migration, that ownership matters.
Before migrating, identify who owns these files, whether that owner is moving, whether access will continue, and whether the organization needs its own managed copy. Shared-in files should be reviewed separately rather than disappearing into a general “Drive data” audit.
Build a migration map before you move anything
Once you understand the source, define what should happen in the destination.
| Source | Question | Destination decision |
|---|---|---|
| Users | Does this account need to move? | Migrate, archive or exclude |
| OUs | Does the current structure still make sense? | Map or redesign |
| Groups | What access depends on this Group? | Recreate and map membership |
| My Drive | Who owns the content? | User, Shared Drive or exclude |
| Shared Drives | Who needs access? | Map membership and roles |
| External files | Who actually owns them? | Preserve access or create managed copy |
| Permissions | How is access granted? | Preserve, change or remove |
| Suspended users | Is their data still required? | Transfer, retain or archive |
This table becomes the reference point for the migration itself.
More importantly, it’s what makes exceptions visible before they turn into post-migration problems.
If your policy on suspended users isn’t already clear, settle how you’ll handle archived and inactive accounts before the migration starts, not partway through it.
Run a representative pilot
Resist the urge to pick your easiest ten users just because they’re easy.
Choose people who represent the actual complexity of the environment:
- – Large Drive accounts
- – Multiple Shared Drive memberships
- – Group-based access
- – External collaborators
- – Shared-in files
- – Heavy Calendar use
- – Delegated access
- – Different organizational units
The goal is to find gaps in the migration plan before they affect the wider organization. After the pilot, compare the source and destination to confirm accounts, files, ownership, permissions, Groups, Shared Drive roles, and external access migrated as expected. Expand the migration only once those checks hold up.
What can get left behind in a Google Workspace migration?
The answer depends on the migration method, but several categories deserve particular attention because they can sit outside the obvious migration scope.
- – Externally owned files: The user can access them, but the organization doesn’t own them.
- – Personal Gmail-owned content: Business data can remain controlled by an identity nobody in the organization manages.
- – Suspended-user data: An account may no longer be active while its content is still important to the business.
- – Group-based access: Moving a user doesn’t automatically answer how every Group relationship should work in the destination.
- – External collaborators: Someone who legitimately needed access in the source environment may not need it after a merger, divestiture or restructuring.
- – Third-party dependencies: Applications, OAuth relationships, and workflows can depend on identities or configurations that exist only in the source environment.
A good migration inventory therefore asks two questions, not one: What data do we have? and What depends on this environment?
How do you know a Google Workspace migration was successful?
A migration report will tell you whether the job completed.
It won’t tell you whether the destination environment is actually correct.
The strongest validation is comparing the destination against the baseline you built before migration.
Source baseline
Users → Ownership → Shared Drives → Groups → Permissions → External access
Destination state
Users → Ownership → Shared Drives → Groups → Permissions → External access
Investigate anything that differs from what you expected.
The question stops being: “Did everything migrate?”
It becomes: “Does the destination match the ownership and access model we set out to create?“
Review the environment again after 30 and 90 days
Post-migration validation shouldn’t end on cutover day.
Some problems only surface once employees settle back into normal work.
Run another review around 30 days after migration, and again near the 90-day mark.
Watch for new external sharing, files owned by unexpected accounts, unused legacy accounts, orphaned content, changes to Shared Drive membership, permissions that shouldn’t exist, access problems reported by users, and dependencies on the old environment that somehow never went away.
These follow-up reviews confirm whether the destination is still aligned with the model you actually intended.
Google Workspace Migration Checklist
The whole process comes down to five stages.
1. Audit: Understand the source environment, including users, data, ownership, sharing and access.
2. Map: Define what the destination should look like: identities, Groups, OUs, ownership, Shared Drives and permissions.
3. Migrate: Start with a representative pilot before moving larger groups.
4. Validate: Compare the destination against your source baseline and investigate anything unexpected.
5. Review: Audit the environment again after 30 and 90 days.
How GAT Labs supports Google Workspace migration planning
GAT Labs doesn’t need to run the entire migration to play an important role in the process. It helps Admins understand, prepare, and validate the environment around the move.
Audit & Validate
GAT+ gives Admins domain-wide visibility before and after migration, helping teams review Drive ownership, sharing, users, Groups and other Workspace activity against the environment they’re planning to move.
Prepare & Manage
GAT Flow helps coordinate the user and directory changes surrounding the migration, including bulk changes and Google Workspace lifecycle workflows for accounts, Groups, organizational information and licensing.
Protect Sensitive Changes
GAT Unlock adds approval-based control to sensitive administrative actions involving areas such as file ownership, permissions and copies of files or folders.
Together, they support the process around the migration:
Audit → Prepare → Migrate → Validate
See how the process fits together on the Google Workspace Domain Migration solution page, or schedule a demo to discuss your environment.
Frequently Asked Questions
1. How do I migrate from one Google Workspace domain to another?
Start by defining the source and destination environments and choosing the appropriate migration or transfer method. Audit users, data, ownership, permissions, Groups and external access before moving anything. Map destination identities, test with a representative pilot, complete the migration and compare the destination against your source baseline.
2. Is Google Workspace Domain Transfer the same as a Google Workspace migration?
No. Google Workspace Domain Transfer is a specific Google offering for eligible Google-to-Google scenarios. Other migration approaches may copy or migrate individual services and data rather than transferring the environment in the same way.
3. What should I audit before a Google Workspace migration?
Audit users, OUs, Drive ownership, Shared Drives, Groups, permissions, external and public sharing, suspended and inactive accounts, shared-in files, storage and important dependencies on the source environment.
4. What happens to Google Drive permissions during migration?
It depends on the migration method and identity mapping. Permissions can reference users, Groups, domains and external identities, so Admins should define how those identities map to the destination and validate the resulting access after migration.
5. What happens to externally owned Google Drive files?
Externally owned files remain controlled by their external owner unless an appropriate migration or ownership process changes that relationship. Identify shared-in content before migration so important business files aren’t mistaken for organization-owned data.
6. How should you validate a Google Workspace migration?
Compare the destination against a documented source baseline. Check users, files, ownership, Shared Drives, Groups, permissions and external access rather than relying solely on migration completion status.
Insights That Matter. In Your Inbox.
Join our newsletter for practical tips on managing, securing, and getting the most out of Google Workspace, designed with Admins and IT teams in mind.
