GuideGeeplo guides

How to transfer Google Drive files to another account (in bulk, keeping ownership sane).

A person leaves, a company splits, an acquisition lands: the Drive has to move with the work. This page walks Google's own routes first, honestly — the per-user transfer for one leaver, the org-size routes for whole tenants, and why a “completed” status is not the same as files you can open at the destination. Then it names the point where those routes stop scaling, many users at once with ownership you can account for, and what the Geeplo Transfer Tool does there.

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

Google's own routes, honestly

Google gives Workspace administrators two families of routes, and the honest answer starts with them, because for the small case they are genuinely the right answer.

• Whole tenant to whole tenant, Google routes the move by organization size. Depending on the size of your organization, the route is Google's data import service, GWMME, or a domain transfer. Check Google's current guidance for your size when you plan, because the routing follows the product.
• One account to one account, Google's per-user transfer exists and works: an admin picks the source user, the destination user, and starts the run. That is the leaver route below.
• What Google does not ship is a bulk ownership utility. There is no Google tool that takes many users' Drive files at once and hands the ownership over in one pass. “Transfer Google Drive ownership to another account” at scale is the gap this page is about.

Do you need to generate a transfer token?

No. None of Google's Drive transfer routes — the per-user transfer, the data import service, GWMME, a domain transfer — asks you to generate a token. The “transfer token” you may have read about sits on Google's billing side, not the Drive side: it is not how files move between accounts. If a guide starts with “first, generate your transfer token” for a file move, it is describing the wrong flow, or inventing a step. Generating a token is not part of moving Drive files; picking the route for your case is.

The leaver handover, one account at a time

The case every admin knows: someone leaves on Friday, and their files are somebody else's problem on Monday. Done natively, the handover is short.

• Use the per-user transfer for a one-off. For one leaver and one successor, Google's per-user transfer is the honest tool: it exists, it is free, and for one person it is the whole job. Choose the destination account, start the transfer, let it run.
• Grant day-one access directly if Monday cannot wait. A transfer takes time to run through; access you grant in the source today is there immediately, and the transfer catches up behind it.
• Shared Drives are not part of a user's transfer. A leaver's My Drive moves with the per-user transfer; a Shared Drive belongs to the organization, not to the member, so the leaver's Shared Drive work stays put and the membership change is a separate admin task.
• Verify by opening, not by status. When the transfer reports done, have the successor confirm the folders are there, the file count looks right, and a few files open — before you suspend the leaver's account.

“It says completed, but nothing has happened”

The most-reported failure mode in Google's transfer tooling: the status, in the Admin console or from the Data Transfer API, reports the job as completed — and the destination account looks unchanged. Nothing in the status tells you which of those two pictures is true. Treat it as the trust gap it is:

• Read “completed” as “the job ended”. The tooling reports on the job, not on the result. Whether the files landed where you expected is a separate check, and no status line does it for you.
• Check what actually moved at the destination. Sign in to the destination account and look: do the folders exist, does the file count match the source, do sample files open, and who owns them? Ten minutes at the destination tells you more than any status page.
• Compare counts, then owners. A run can land the files without the ownership you expected, or report completed while some files never arrived. The file count and the owner on a handful of files are the two checks that catch both.
• If the destination is empty, the run did not do what you asked. Re-check that the transfer covered Drive data and the right source and destination accounts, run it again, and verify the same way.

Where Google's routes stop scaling

One leaver is an admin task. Bulk is a different shape of problem, and it is where the native routes end:

• Many users at once. The per-user transfer is one user per run. A department of leavers, an acquisition, a split: that is the same run repeated per person, with who-is-done tracked by hand.
• Ownership you can account for. With no bulk ownership utility on Google's side, “who owns what” after a multi-user move is whatever you can verify file by file.
• A result you can check. Google's routes report on the job, not item by item; a list of what failed, with the cause, is not part of any of them.

This is the point where the Geeplo Transfer Tool exists, and the honest description of it is short. It runs bulk transfers across many users in one batch, with accounts auto-mapped and validated before anything moves. For each drive you choose copy or move: a copy leaves the source intact, a move takes the files with it and is marked destructive in the wizard before you create the batch. Interrupted tasks resume without re-copying finished files. Tasks that keep failing are marked Dead Letter with the cause; you fix the cause, then press Retry Failed, and finished items are skipped.

Where this fits

The Google Workspace offboarding guide covers the wider leaver checklist this transfer slots into; the tenant-to-tenant migration guide covers the whole-tenant case end to end; and the Transfer Tool page details the twelve migration types, user auto-mapping and the wizard behind the bulk route.