GuideGeeplo guides

Google Workspace tenant-to-tenant migration: your options, and when each works.

An acquisition lands and two Workspaces become one, a company splits in two, or the business rebrands onto a new primary domain: the job is a whole Google Workspace moved to another Google Workspace. This page starts with Google's own routes and their constraints, in Google's words — the routing by organization size, what Domain Transfer Divestiture can and cannot move. Then it answers the two questions that follow: what determines how long the move takes, and why a delegation 401 stops one cold. Where those native routes leave a gap, it says so plainly, and says what the Geeplo Transfer Tool does there.

Written by the Geeplo team. Reviewed by Miguel Perez, co-founder. Last updated November 1, 2026.

Your options, and when each works

Google documents its migration routes in one place, the migration product matrix, and for Workspace-to-Workspace it routes by organization size. The honest answer to “what are my options” is that matrix, with its constraints left exactly as Google states them:

• Smaller organizations: the data import service. For a Workspace-to-Workspace move, the matrix routes organizations of 1–100 users to Google's data import service.
• Mid-size: GWMME. From 101 to 1,000 users, the matrix routes the move to GWMME, Google's migration tool.
• Larger: Domain Transfer. From 1,001 users up, the matrix routes to Google Workspace Domain Transfer.
• What Divestiture moves. Domain Transfer Divestiture transfers secondary domains “from one of your organization's Google Workspace accounts to another” — run by Google Cloud Professional Services, takes on the order of a day, and the data moves rather than copies.
• What it cannot move. “Primary domains can't be transferred”, Google states in its transfer options doc. The divestiture route moves domains between accounts inside one organization; two independent companies merging two separate Workspaces is a different case, and the org-size routes above are Google's documented path for it.

One boundary, honestly: moves in the other direction — Microsoft 365 or IMAP into Workspace, or Workspace out to another platform — are a different problem this page does not cover.

How long does a Google Workspace migration take?

There is no single answer, and a tool that quotes one before looking at your tenant is guessing. Four things set the duration, and all four are yours to size before the batch starts:

• The scope you actually move. Every account or a subset, every workload or only drives and mail: the scope you pick, not the calendar, is the first variable.
• The data types in that scope. Drives, Shared Drives, mail, calendars, contacts, notes, groups and chat each behave differently in a move. A tenant that is mostly Shared Drives is a different job from one that is mostly mail, even at the same account count.
• Delegation readiness on both tenants. A tenant-to-tenant move runs on domain-wide delegation, and readiness work done late shows up as delay. The Transfer Tool will not start until the source tenant's delegation has been verified in the last 7 days; Geeplo checks the source for you, and the destination is yours to check.
• The verification you owe the result. A migration is done when someone has checked the destination — file counts, owners, a few files opened — not when a status line says finished. Plan the verification time as part of the duration, because it is.

What is the Google Workspace migration tool?

There is no single one — and that is the finding. Google ships a routing, not one product: the data import service, GWMME and Domain Transfer, picked by organization size on the matrix above. What Google's migration docs cover in depth is the inbound direction, where Exchange, SharePoint, OneDrive, Teams, Dropbox, Box, PST and IMAP each have their own documented routes. The Workspace-to-Workspace row is the thin one: a routing by size, plus the divestiture constraints above. So when you search for “the Google Workspace migration tool” for a tenant-to-tenant move, the honest answer is: the route changes with your org size, the domain route is bound to secondary domains inside one organization, and no one Google tool carries the whole Google-to-Google job at every size. Whatever route the matrix hands you, the admin still owns user mapping, copy-or-move decisions, delegation and verification.

The delegation 401: what it is, and when it bites

Tenant-to-tenant tooling works through a service account authorized in Domain-wide delegation, acting as your users to read and write on their behalf. A 401 is Google's API refusing that: the request arrives without a delegation grant Google will honor. It is the error that turns a planned cutover into a standstill, and it is avoidable:

• When it bites: delegation never granted on one of the two tenants, granted to the wrong client ID, a scope list that does not cover the workloads in the batch, the client removed mid-project by a cleanup pass, or a grant that has not been verified anywhere near the cutover date.
• How Geeplo orders it: the Transfer Tool works through domain-wide delegation on the tenants it connects, and won't start a migration until the source tenant's delegation has been verified in the last 7 days. Geeplo checks the source for you; check the destination yourself.
• How to avoid it: authorize the service account in both Admin consoles under Security > API controls > Domain-wide delegation before planning week, grant exactly the scopes listed on the scopes page, and leave the client in place until the migration is signed off — revoking mid-run is a 401 you scheduled yourself.

Where the native routes end, and bulk begins

The matrix routes by size, but size is not the only axis: many users at once across two tenants — a merger consolidating two Workspaces, a split carving one into two — is the case where the per-run native routes leave the tracking to you, and the domain route is bound to secondary domains inside one organization. This is the point where the Geeplo Transfer Tool exists, and the honest description is what it does. It runs tenant-to-tenant transfers across twelve migration types — My Drives, Shared Drives, Gmail, Calendar, Contacts, Keep Notes, Groups, Chat spaces and calendar resources — picked in one wizard. For each drive you choose copy or move; a move is marked destructive in the wizard before the batch is created. Every workload runs as its own task in the batch, so a slow drive does not hide a finished mailbox. Interrupted tasks resume without re-copying finished files. Tasks that keep failing are marked Dead Letter with the cause — you'll know what failed and why — and after you fix the cause, Retry Failed picks up where the batch stopped, skipping finished items.

Where this fits

This page answers “what are my options, and when does each work”. If you already know your route and want the execution list, the Google Workspace migration checklist is the companion: the same job, ordered before, during and after. For one person's Drive rather than a whole tenant, see the Drive transfer guide; for the leaver checklist a move slots into, see the Google Workspace offboarding guide; and the Transfer Tool page details the wizard, the scopes and the twelve migration types.