One Drive to Rule Them All: Consolidating Mail, Files and Media from Many Accounts into Google Drive

Written with the help of Claude AI

The problem: one person, too many accounts

Most people don't plan their digital footprint. They accumulate it. A personal Gmail from university, an Outlook.com address from an old job, a OneDrive that came free with an Office subscription, a second Google account set up for a side business. Years later, the emails, documents, spreadsheets and family photos are spread across all of them.

That was the situation for a recent client. They had moved onto a Google Workspace account on their own domain and wanted everything else consolidated there: mail into the Workspace mailbox, and every file, folder, photo and video into a single, organised Google Drive.

It sounds like a copy-and-paste job. It isn't. This post walks through the four stages we went through, the traps we hit along the way, and the scripts that got us out of them.

The overall plan was simple:

Move each mailbox into the Workspace account.
Copy each account's files into Google Drive, one top-level folder per source account.
Clean up the side effects of the copy.
Pull all photos and videos out into a single Media folder.

Step 1: Email — moving every mailbox into Workspace Gmail

Mail is the easiest piece to verify and the one people miss most when it's gone, so we did it first. The right tool depends entirely on where the mail lives today:

Source mailbox	Best route into Workspace Gmail	Needs
Personal Gmail	Admin console data import tool (Gmail source)	Workspace super admin; the Gmail owner approves a request
Personal Outlook.com / Hotmail	Classic Outlook for Windows + Google's GWMMO tool (via PST)	A Windows PC with desktop Outlook
Any other IMAP provider (Yahoo, iCloud, Zoho...)	Admin console data import tool (IMAP source)	The mailbox password or an app password

Whichever route you take, moving the mail is only half the job. The other half is telling the rest of the world about the new address, and that part is manual.

Personal Gmail to Workspace Gmail

Google Workspace has a built-in, free data import tool that pulls mail directly from a personal Gmail account into a Workspace mailbox, labels and all. Nothing is downloaded or re-uploaded. It used to be called the Data Migration Service, and older guides (including our own first notes) mention app passwords. The current version uses an authorisation request instead, which is simpler and safer.

Before you start

You need a super administrator login for the Workspace tenant.
The target user must have a Workspace licence with Gmail turned on.
If the personal Gmail account is enrolled in Google's Advanced Protection Program, it has to be turned off before the import is set up and for as long as it runs.

Step by step

In the Admin console, go to Menu → Data → Data import & export → Data import.
Under Gmail, click Import.
Enter the personal Gmail address as the Source email address and click Request authorization.
The Gmail account owner gets an email and approves the request. If you own the account, you can approve it directly from the Admin console. The request expires after 24 hours; use Refresh request to resend.
Once the status shows Connected, enter the Workspace address as the Target account and click Save.
Choose the import settings. With no start date, everything from 1 January 2000 onward is imported. Optionally include deleted and spam messages, or exclude labels by name (sub-labels as Parent/Child).
Click Start import. Progress counts update live: emails discovered, imported, skipped and failed. You can close the page; Google emails a report when it finishes.
Run a delta import later to pick up anything that arrived in the old account after the first pass.

What carries over, and what doesn't

Mail and labels come across. Contacts, calendars, filters, signatures and the old account's "Send mail as" settings do not. For a single person these are quick by hand:

Contacts: export from Google Contacts on the old account (Google CSV), import on the new one.
Calendars: export from Google Calendar settings (.ics) and import, or simply share the old calendar with the new account.
Filters: Gmail settings → Filters → export as XML on the old account, import on the new one.

Bridging the gap

Until everyone has the new address, set the old Gmail to auto-forward to the Workspace address (Settings → Forwarding and POP/IMAP). Add a filter in the new mailbox that labels anything sent to the old address. That label becomes your to-do list for the subscription clean-up below.

Google's full walkthrough: Import email with the data import tool.

Personal Outlook.com to Workspace Gmail

This is the awkward one. The data import tool's IMAP option asks for the mailbox password, and personal Microsoft accounts (@outlook.com, @hotmail.com, @live.com) stopped accepting passwords and app passwords over IMAP in September 2024. Only modern sign-in (OAuth) works now. The data import tool's Exchange Online option is built for business Microsoft 365 tenants, not personal accounts.

So the reliable route goes through a Windows PC and two pieces of desktop software: classic Outlook, which signs in to Outlook.com properly, and Google's free GWMMO (Google Workspace Migration for Microsoft Outlook), which imports a PST file into a Workspace account.

Step by step

Install classic Outlook for Windows (Outlook 2021 or the Microsoft 365 desktop app). Older versions, and the web, Mac and "new Outlook" apps, won't work for this.
Add the Outlook.com account using automatic setup, so it connects with a Microsoft sign-in page rather than a password box. Let it sync completely; for a large mailbox, set the offline cache to keep all mail, not just the last year.
Export to PST: File → Open & Export → Import/Export → Export to a file → Outlook Data File (.pst). Select the top of the mailbox and tick Include subfolders.
Install GWMMO from Google's download page, with Outlook closed.
Run GWMMO, sign in with the Workspace account, and choose From PST file(s) as the source.
Pick what to import: email, calendar and contacts can go together or separately. Optionally skip junk and deleted items, or limit by date.
Start the import and leave the PC on. Outlook folders become Gmail labels.

If the PST is too large to export cleanly, export it in date ranges or folder by folder and run GWMMO once per file.

Other routes we considered

Route	When it makes sense	Catch
Thunderbird with both accounts added (OAuth for Outlook.com), drag folders across	No Windows PC, small mailbox	Slow, manual, easy to miss folders
imapsync with OAuth access tokens	Comfortable on the command line	Getting a Microsoft OAuth token is the fiddly part
Commercial migration services	Several mailboxes, little time	Paid; you hand a third party access to both accounts
Data import tool, IMAP option	Other IMAP providers (Yahoo, iCloud, Zoho)	Doesn't work for Outlook.com any more

Bridging the gap

In Outlook.com, turn on forwarding to the Workspace address (Settings → Mail → Forwarding) and tick Keep a copy. As with Gmail, a filter in the new mailbox labels anything that arrives via the old address.

The manual part: subscriptions, logins and the old address

No tool moves this part for you. Every bank, utility, shop, school portal and newsletter knows the old address, and each one has to be changed by hand on its own website. This took longer than the mail import itself.

1. Build the list

We built an inventory from three places, in a simple sheet with columns for service, old address, category, changed (yes/no) and notes:

The old mailboxes. Search them for words that only service emails use: unsubscribe, receipt, invoice, verify your email, password reset, welcome to, your order. Sort by sender and you have most of the list in an hour.
The password manager (or the browser's saved passwords). Every saved login whose username is the old address is a service to update.
"Sign in with Google" and "Sign in with Microsoft". Check the old account's security page for third-party apps with account access. These logins are tied to the old account, not just its address, and are covered below.

2. Work through it by priority

Priority	Examples	Why
First	Banks, cards, tax, government portals, insurers, utilities	Missing one of these has real consequences; many need extra verification to change
Second	Phone carrier, domain registrar, cloud and software subscriptions, shopping accounts with saved payment	Billing and account recovery depend on them
Third	Social media, forums, loyalty schemes	Nice to have; batch them
Last	Newsletters and marketing	Unsubscribe from most rather than moving them; it's a free clean-up

For each service: log in, change the email, confirm the verification link that arrives in the new mailbox, and tick it off. Where a site won't let you change the email, note it and decide whether to keep the old account just for that service or close and re-register.

3. The things that don't move

Purchases and subscriptions tied to the account itself. Apps, films and books bought on Google Play, YouTube or Google One subscriptions on the old Google account, and a Microsoft 365 Personal subscription on the old Microsoft account stay with those accounts. Cancel and re-subscribe on the new account where it makes sense, or keep the old account for them.
"Sign in with Google/Microsoft" logins. Most sites let you add a password or link a new sign-in method from their account settings. Do that before you stop using the old account.
Recovery details. Make the new address the recovery email on anything important, and check the old accounts' own recovery phone and email are still current.

4. Don't delete the old accounts

Keep the old Gmail and Outlook.com accounts open, forwarding to the new address, for at least six months to a year. The "via old address" label shows what you missed; when it's been quiet for a few months, you're done. Sign in to each old account every so often: both Google and Microsoft can close personal accounts that sit unused for long enough, and the old address is still the recovery route for anything you forgot.

Step 2: Files — rclone, and the spreadsheet that vanished

For files, we used rclone, which talks to Google Drive, OneDrive and dozens of other storage services. Each source account got its own top-level folder in the destination Drive, named after the account. That kept provenance clear: you can always tell where a file came from.

Setting up the remotes

In rclone, each account is a remote. We created one per source account and one for the destination. The names below are placeholders:

Remote	Type	Scope (recommended)	Role
`src-g1:`	Google Drive (personal)	`drive.readonly`	Source
`src-g2:`	Google Drive (second account)	`drive.readonly`	Source
`src-od:`	OneDrive Personal	default	Source
`dst:`	Google Drive (Workspace)	`drive`	Destination

A Google Drive remote is created with rclone config. The answers that matter:

rclone config
n) New remote
name> dst
Storage> drive
client_id> 1234567890-xxxx.apps.googleusercontent.com   # your own, see below
client_secret> GOCSPX-xxxx
scope> 1                         # "drive" = full access (destination)
service_account_file>            # blank
Edit advanced config? n
Use web browser to automatically authenticate? y
Configure this as a Shared Drive (Team Drive)? n
Keep this "dst" remote? y

A few settings are worth calling out:

client_id / client_secret. Leaving these blank uses rclone's shared client ID, which is being retired in 2026. Create your own. The next section covers why and how.
scope. Use drive (full access) on the destination. On source accounts, drive.readonly is the safer choice: rclone can read and download but cannot rename or delete anything. We learned this the hard way in Step 3.
Shared Drive. Answer y only if the destination is a Shared Drive rather than a user's My Drive.
Browser authentication. rclone opens a local web page on 127.0.0.1:53682 to receive the token. On a machine without a browser, answer n and use rclone authorize on another machine.

For OneDrive, choose Storage> onedrive, keep the region as global, sign in through the browser, then pick the OneDrive Personal drive when prompted. Office files in OneDrive are real .docx and .xlsx files, so they don't have the export problem described below.

Before copying anything, check each remote can see what you expect:

rclone listremotes
rclone lsd src-g1:          # top-level folders
rclone size src-g1:         # file count and total size
rclone about dst:           # free space on the destination

The copy commands

Each source went into its own folder under the destination. Always start with a dry run:

rclone copy src-g1: "dst:Users/Account A" --dry-run -v

Then the real run, with logging and progress:

rclone copy src-g1: "dst:Users/Account A" \
  --drive-export-formats ods,odt,odp \
  --drive-import-formats ods,odt,odp \
  --fast-list --transfers 4 --checkers 8 \
  --drive-stop-on-upload-limit \
  --log-file accountA.log -v -P

rclone copy src-od: "dst:Users/Account C" \
  --fast-list --transfers 4 \
  --log-file accountC.log -v -P

Flag	What it does	Why we used it
`--dry-run`	Lists what would happen without changing anything	Always first
`--drive-export-formats ods,odt,odp`	Exports native Sheets, Docs and Slides as OpenDocument files	Avoids name clashes with real Office files (explained below)
`--drive-import-formats ods,odt,odp`	Converts those files back to native Google files on upload	Sheets arrive as Sheets, not `.xlsx`
`--fast-list`	Batches directory listings into fewer API calls	Much faster on large folder trees
`--transfers 4 --checkers 8`	Parallel uploads and comparisons	Stays under Drive's per-client rate limits
`--drive-stop-on-upload-limit`	Stops cleanly at Drive's 750 GiB/day upload cap	Re-run the next day instead of hammering errors
`--log-file ... -v`	Writes every action to a log	An audit trail, and a way to reverse mistakes
`-P`	Live progress	Visibility on long runs

copy never deletes anything at the destination, which is why we used it instead of sync. Because it skips files that already match, re-running the same command after an interruption simply resumes.

To verify regular files after each run:

rclone check src-g1: "dst:Users/Account A" --one-way --drive-skip-gdocs

Native Google files report no size, so check can't compare them. We spot-checked those by hand.

That's the clean version. Here's what went wrong the first time, before those export flags were added.

The copy ran fine until we checked the spreadsheets. Some native Google Sheets were simply missing at the destination.

Why it happened

A native Google Sheet isn't a file on disk. When rclone copies one between accounts, it exports it to a real format, by default .xlsx, and uploads that. The source folders often had a Google Sheet and a genuine Excel file with the same name sitting side by side, for example Budget (Sheet) and Budget.xlsx (Excel). After export, both became Budget.xlsx, and rclone treated one as a duplicate of the other.

The obvious fix, rclone's dedupe command, made things worse. It renamed the Sheets to Budget-1, Budget-2 and so on, and they then arrived at the destination as plain .xlsx files rather than native Sheets. Formulas survived; the Google-native file did not.

For the record, the command that caused the trouble was:

# Don't do this to fix export collisions
rclone dedupe --dedupe-mode rename src-g1:

rename mode is designed for genuine duplicate files, which Drive allows and most storage doesn't. It renames every item that shares a name, and it does so on the live remote. With a read-only scope on the source, this command would simply have failed.

Fix A: round-trip through ODS

The cleaner rclone fix is to export native Google files to a format that doesn't collide with anything real, then convert them back on upload:

rclone copy src:Folder dst:Folder \
  --drive-export-formats ods,odt,odp \
  --drive-import-formats ods,odt,odp \
  --dry-run -vv

Sheets, Docs and Slides travel as .ods, .odt and .odp, so they no longer clash with real .xlsx, .docx and .pptx files, and they're re-imported as native Google files at the other end. Everything else (PDFs, Word and Excel files, images) is copied byte for byte. Drop --dry-run once the listing looks right.

Two caveats: any genuine .ods files in the source will also be converted to Sheets, and some advanced features (bound Apps Script, certain charts and pivots) may not survive the conversion.

Fix B: Apps Script for true native copies

Where the source account can share folders with the destination, Google Apps Script avoids conversion entirely. DriveApp's makeCopy() produces a genuine native copy of any file type. Share the source folder with the destination account, then run a recursive copy as the destination user:

function copyTree() {
  const SRC_ID = 'SOURCE_FOLDER_ID';
  const DST_ID = 'DESTINATION_FOLDER_ID';
  copyFolder_(DriveApp.getFolderById(SRC_ID), DriveApp.getFolderById(DST_ID));
}

function copyFolder_(src, dst) {
  const files = src.getFiles();
  while (files.hasNext()) {
    const f = files.next();
    const name = f.getName();
    if (!dst.getFilesByName(name).hasNext()) f.makeCopy(name, dst);
  }
  const subs = src.getFolders();
  while (subs.hasNext()) {
    const s = subs.next();
    const existing = dst.getFoldersByName(s.getName());
    const d = existing.hasNext() ? existing.next() : dst.createFolder(s.getName());
    copyFolder_(s, d);
  }
}

Because it skips files that already exist, the script is safe to re-run when it hits Apps Script's execution time limit (about 6 minutes on personal accounts, 30 on Workspace). The trade-offs: copied files get new modified dates, and files the owner has restricted from copying will fail.

Our rule of thumb: large file counts, or a source that blocks external sharing, go through rclone with ODS. Otherwise, Apps Script is the only option that guarantees native files.

A 2026 gotcha: rclone's shared Google client ID is going away

If you set up rclone for Google Drive by pressing Enter at the client_id prompt, you're using a client ID shared by every rclone user in the world. That stops working in 2026.

In July 2026, the rclone maintainers announced that Google will start charging for API requests made through rclone's built-in client ID for Drive and Google Photos. Google's stated timescale is later in 2026, after 90 days' notice. rclone's usage is hundreds of times over the free quota, so the project plans to disable the shared ID before charging starts and then remove it from the code (tracking issue). Recent releases already print a warning when a remote uses it.

The exact date is still open. In mid-September the maintainer said Google had gone quiet and might be revising the plan. Don't wait for it: a migration that breaks halfway through is far worse than ten minutes of setup.

Check whether you're affected

rclone config show dst:

If client_id and client_secret are blank or missing, the remote uses the shared ID. Remotes that use a service account are not affected. Check every Drive and Google Photos remote.

Fix: create your own client ID

The rclone Drive docs have the full walkthrough. In outline:

In the Google Cloud console, create a project (any Google account works) and enable the Google Drive API.
Configure the OAuth consent screen: app name, support email, audience External (or Internal if every account involved is in one Workspace).
Under Data access, add the scopes auth/docs, auth/drive and auth/drive.metadata.readonly.
Under Audience, add yourself as a test user.
Create an OAuth client of type Desktop app and note the client ID and secret.
Publish the app (External only). If Publish App is greyed out, fill in a homepage and privacy policy URL under Branding first.
Add the ID and secret to the remote with rclone config, then run rclone config reconnect dst: and refresh the token. Without the reconnect, rclone keeps using the old shared credentials.

One client ID can serve all your remotes, but each remote needs its own reconnect.

Things that catch people out:

Unverified app warning. Google shows a scary screen at sign-in. For personal use (under 100 users), you can click through it; verification isn't required.
Testing mode expires tokens after 7 days. Publish the app to avoid re-authorising every week.
Unused clients can be deleted. Google may remove OAuth clients inactive for six months.
Advanced Protection accounts block unverified apps from requesting Drive scopes, so a self-made client ID won't work there.
A bonus: your own client ID gets its own rate limit, so transfers are often noticeably faster.

Alternatives if you can't (or won't) make a client ID

Option	Works for	Trade-offs
Your own OAuth client ID in rclone	Any Google account	10 minutes of Cloud console setup; recommended default
Service account with domain-wide delegation + `--drive-impersonate`	Workspace accounts you administer	Ideal for the destination; can't reach consumer Gmail accounts
Google Apps Script with `makeCopy()` (Step 2, Fix B)	Any account that can share folders	No OAuth client needed; time limits; resets modified dates
Google Takeout, then upload via Drive for Desktop	Any Google account	No API at all; slow, manual, Sheets arrive as `.xlsx`
Drive for Desktop on both accounts, drag between them	Small jobs	Simple; native Google files sync as shortcut stubs, not content
Workspace admin migration tools	Workspace destination	Built in; less control over folder layout

In a setup like this one, a service account could cover the Workspace destination, but the personal source accounts still need a client ID. The simplest answer is one client ID, created once and used on every remote.

Step 3: Undoing the dedupe renames

The failed dedupe run had left dozens of Sheets in the source Drive renamed Name-1, Name-2. There's no undo button for this. Drive's version history tracks file content, not renames, and rclone keeps no rollback log unless you saved its verbose output.

So we wrote one more Apps Script to rename them back in place. The important part is what it refuses to touch. A file is only renamed if all three of these are true:

It's a native Sheet, Doc or Slides file whose name ends in -<number>.
A matching real .xlsx, .docx or .pptx with the original base name sits in the same folder.
No other native file of the same type already has the original name.

That way, a legitimate file called Budget-2 with no Excel twin is left alone.

const DRY_RUN = true;  // set to false after checking the log
const EXT = {};
EXT[MimeType.GOOGLE_SHEETS] = '.xlsx';
EXT[MimeType.GOOGLE_DOCS]   = '.docx';
EXT[MimeType.GOOGLE_SLIDES] = '.pptx';

function undoDedupe() {
  walk_(DriveApp.getFolderById('SOURCE_FOLDER_ID'));
}

function walk_(folder) {
  const files = folder.getFiles();
  while (files.hasNext()) {
    const f = files.next();
    const ext = EXT[f.getMimeType()];
    if (!ext) continue;

    const m = f.getName().match(/^(.*)-\d+$/);
    if (!m) continue;
    const base = m[1];

    // Only if the real xlsx/docx/pptx twin exists
    if (!folder.getFilesByName(base + ext).hasNext()) continue;

    // Skip if a native file of the same type already has the original name
    let clash = false;
    const same = folder.getFilesByName(base);
    while (same.hasNext()) {
      if (same.next().getMimeType() === f.getMimeType()) { clash = true; break; }
    }
    if (clash) { Logger.log('SKIP (clash): ' + folder.getName() + '/' + f.getName()); continue; }

    Logger.log((DRY_RUN ? 'WOULD RENAME: ' : 'RENAMED: ') +
               folder.getName() + '/' + f.getName() + ' -> ' + base);
    if (!DRY_RUN) f.setName(base);
  }
  const subs = folder.getFolders();
  while (subs.hasNext()) walk_(subs.next());
}

Run it with DRY_RUN = true, read the execution log, then flip it to false. It's safe to re-run after a timeout, because files already renamed no longer match the pattern. Anything logged as SKIP (clash) needs a human decision.

One detail made this whole fix possible: inside Drive, a native Sheet called Budget and a file called Budget.xlsx never actually collide. The collision only exists when a tool exports the Sheet. Restoring the original names was safe.

Step 4: Gathering photos and videos into one Media folder

With everything in one Drive, the last request was the one the client cared about most: all photos and videos in one place, regardless of which account they came from.

The Drive web interface can filter by file type, but it flattens results into one long list, has no bulk move by extension, and loses track of which account and subfolder each file came from. With thousands of files, that's a non-starter.

Instead we used Google Drive for Desktop on a Windows laptop and a PowerShell script run against its virtual drive. The key insight: a move within the Drive for Desktop drive (for example G:\) is sent to Google as a Drive move, not a download and re-upload, even in Stream mode. File IDs, sharing settings and version history are preserved. Only metadata changes.

The script works like this:

It scans the account folders recursively for image and video extensions (JPEG, PNG, HEIC, camera RAW formats, MP4, MOV, MKV and so on).
It moves each match to Media\<AccountFolder>\<original subfolders>\, so provenance is kept and the inevitable dozens of IMG_0001.jpg files from different phones don't collide.
It never overwrites. Name clashes get (1), (2) suffixes.
It runs as a dry run by default and writes a CSV log of every planned move.
An optional switch removes folders left empty afterwards. They go to Drive's trash, so they're recoverable.

The core of it:

param(
    [string]$Root  = "G:\My Drive\Users",
    [string]$Media = "G:\My Drive\Users\Media",
    [switch]$Execute,
    [switch]$RemoveEmptyFolders
)

$ext = @('.jpg','.jpeg','.png','.gif','.heic','.heif','.webp','.tif','.tiff',
         '.dng','.cr2','.nef','.arw',
         '.mp4','.m4v','.mov','.avi','.mkv','.wmv','.webm','.3gp','.mts','.m2ts')

$rootFull  = (Resolve-Path -LiteralPath $Root).Path.TrimEnd('\')
$mediaFull = (Resolve-Path -LiteralPath $Media).Path.TrimEnd('\')

Get-ChildItem -LiteralPath $rootFull -Recurse -File -Force |
  Where-Object { $ext -contains $_.Extension.ToLower() -and
                 -not $_.FullName.StartsWith($mediaFull + '\') } |
  ForEach-Object {
    $rel  = $_.FullName.Substring($rootFull.Length + 1)
    $dest = Join-Path $mediaFull $rel
    # ...collision handling, dry-run logging, then Move-Item when -Execute is set
  }

The workflow is: run it once as a dry run, review the CSV, then re-run with -Execute (and -RemoveEmptyFolders if wanted). Let the Drive for Desktop tray icon finish syncing before judging the result.

We deliberately left .svg and .ts off the extension list. In a mixed archive they're far more likely to be design assets and TypeScript source than images and video.

For very large collections (tens of thousands of files), a server-side Apps Script avoids the local sync client entirely, at the cost of batching around the execution time limit. For a personal archive, the PowerShell route was simpler and much easier to audit.

Lessons learned

Consolidating accounts is less about moving bytes and more about not breaking things along the way. A few principles carried us through:

Use the platform's own migration tools first. Google's Data Migration Service handled mail with almost no effort. Scripts are for the gaps.
Native Google files are not files. Any tool that copies between accounts has to export them, and that's where names collide and formats change. Know how your tool handles Sheets, Docs and Slides before you run it on real data.
Be wary of "fix" commands. rclone's dedupe did exactly what it says, and created a second problem. Test on a small folder first.
Dry run everything. Every script in this project defaulted to preview mode with a log. That's what made it safe to run against years of irreplaceable photos.
Keep provenance. One folder per source account, preserved all the way into the Media folder, meant we could always answer "where did this come from?"
Moves beat copies. Within the same Drive, a move is a metadata change that preserves sharing and history. A copy creates a new file with a new date.

The end result: one Google Workspace account holding the client's mail, their documents with Sheets still working as Sheets, and every photo and video from every account in a single Media folder.

Search This Blog

Troubleshooter Extraordinaire :)