Migrate Google Workspace to ProtonMail via Bridge

You've decided to move mail off Google Workspace to ProtonMail for privacy, sovereignty, or cost reasons. The mechanics differ from a typical IMAP-to-IMAP move because ProtonMail's at-rest encryption means standard IMAP clients can't talk to ProtonMail servers directly. The bridge between conventional IMAP tooling and ProtonMail's encrypted backend is ProtonMail Bridge, a local app that presents an IMAP/SMTP server on localhost. This guide walks through the source prep, Bridge configuration, the actual migration, and the cutover.

How ProtonMail's architecture changes the migration shape#

Most migrations are conceptually simple: IMAP source server, IMAP destination server, a tool that fetches from one and appends to the other. ProtonMail doesn't fit that shape because ProtonMail servers don't speak standard IMAP. Messages on ProtonMail are encrypted with user-derived keys, and the IMAP protocol has no provision for that kind of encryption.

ProtonMail's answer is Bridge: a small application that runs on each user's workstation, holds their encryption key in memory while running, and exposes a standard IMAP/SMTP server on 127.0.0.1. Mail clients (Thunderbird, Outlook, Apple Mail, and migration tools) connect to Bridge as if it were a normal IMAP server. Bridge handles the encryption transparently and relays to ProtonMail's servers.

This means three things for your migration. First, you can only migrate to one ProtonMail account at a time per workstation (Bridge handles one account). Second, the workstation running Bridge has to stay awake and online for the entire migration. Third, throughput is lower than a typical IMAP-to-IMAP migration because every message has to be encrypted client-side before upload.

Setting expectations#

Be honest about scope and constraints.

Mail content moves through Bridge. Headers, body, attachments, dates, read/unread state, and folder hierarchy come across. So does flagged state.

Encryption is at-rest only. Mail that was plaintext on Gmail remains plaintext in transit through Bridge and only becomes encrypted when ProtonMail stores it. This is not end-to-end encryption between sender and recipient. If end-to-end encryption matters for past mail, this migration won't retroactively provide it.

Gmail labels and ProtonMail labels are different models. Gmail allows many labels per message. ProtonMail supports labels too, but the model has some differences. Most migration tools map Gmail labels to ProtonMail labels with reasonable fidelity, but verify in the pilot.

Calendar, contacts, Drive do not move with mail migration. ProtonMail Calendar exists and supports ICS import. ProtonMail Contacts supports vCard import. Drive doesn't have a destination on Proton's side; you'd move to Proton Drive separately.

Bridge throughput is lower than direct IMAP. Expect 10 to 20 hours per 10 GB instead of 4 to 8 you'd see for direct IMAP. Plan accordingly.

Source-side preparation#

The Workspace side first.

Enable IMAP for users you'll migrate#

In the Workspace Admin Console under Apps → Google Workspace → Gmail → End User Access, ensure IMAP access is allowed. For each user being migrated, IMAP needs to be enabled in their Gmail settings, or you can do it administratively via the Gmail API.

Choose auth method#

Two options. Per-user app passwords (each user generates one at myaccount.google.com/apppasswords; requires 2-step verification enabled). Or OAuth2 if your migration tool supports OAuth against Workspace. For Bridge-based ProtonMail migrations, app passwords are typically simpler because the migration is happening from your workstation rather than a server.

Take a baseline#

Before any data moves, capture per-mailbox stats from Workspace. Item counts, storage sizes, and label hierarchy. Save to CSV.

Plan for parallel execution#

Because Bridge handles one ProtonMail account at a time per workstation, you can parallelize across workstations if you have multiple to dedicate. For 20 mailboxes on 2 workstations, expect roughly half the total wall time. For larger estates, this becomes the practical bottleneck.

ProtonMail and Bridge setup#

The destination side has more setup than a typical IMAP migration.

Provision ProtonMail accounts#

Sign up for ProtonMail for Business or use existing accounts. Verify domain ownership via DNS records. Create users matching your Workspace user list. Confirm storage allocation per user: Proton Mail Plus is 15 GB, Proton Business is 500 GB pooled, Proton Visionary is more.

Install ProtonMail Bridge#

Download Bridge from proton.me/mail/bridge for the OS you're using on the migration workstation. Install. Bridge runs as a system tray application and exposes the local IMAP/SMTP server on 127.0.0.1.

Sign in and capture local credentials#

Open Bridge. Sign in with the first ProtonMail account you'll migrate. Bridge generates a unique IMAP/SMTP password (different from the ProtonMail account password). It also gives you the local IMAP host and port, typically 127.0.0.1:1143 for IMAP and 127.0.0.1:1025 for SMTP. Capture these.

Verify Bridge connectivity#

Before involving the migration tool, test Bridge with a standalone IMAP client. Open Thunderbird, add an account with host 127.0.0.1, port 1143, STARTTLS, username being the full ProtonMail address, password being the Bridge-generated password. Confirm folders list (Inbox, Sent, Drafts, Spam, Trash, Archive, plus any existing labels). Try appending a test message and confirm it shows up in ProtonMail's web interface.

For Bridge connection troubleshooting, see our Bridge connection fix guide.

Step-by-step migration#

1. Confirm Bridge is healthy for the first user

   With Bridge installed and the first ProtonMail account signed in, verify in Bridge's status indicator that the account is connected (green icon, no errors). Open Thunderbird or any IMAP client and confirm you can list folders and append a test message to the local IMAP endpoint. Don't proceed until this works cleanly.

2. Configure source and destination in Mailbox Taxi

   Open Mailbox Taxi. Add the Workspace source: host imap.gmail.com, port 993, SSL, full email as username, app password as password. Add the Bridge destination: host 127.0.0.1, port 1143, STARTTLS, full ProtonMail email as username, Bridge-generated password as password. The tool will enumerate folders on both sides.

3. Configure folder and label mapping

   Gmail's system folders/labels map to ProtonMail equivalents: Sent → Sent, Drafts → Drafts, Trash → Trash, Spam → Spam, Starred → Starred (or skip), Important → skip (Gmail-specific), All Mail → skip. User-created labels should map to ProtonMail labels. Configure the migration tool to use labels rather than folders for these, since Gmail's model is label-based.

4. Run a single pilot mailbox completely

   Don't migrate multiple mailboxes in the pilot, just one. Pick a mid-sized mailbox (5 to 10 GB) with reasonable folder/label complexity. Run the migration to completion. Then open ProtonMail webmail and verify: dates match, attachments open, folder/label structure is what you expected, no obvious duplicates or missing messages.

5. Switch Bridge to the next user and repeat

   ProtonMail Bridge handles one account at a time. To migrate the next user, sign out of the first account in Bridge and sign in with the second. Wait for Bridge to finish initial sync (a few minutes). Verify the new endpoint with Thunderbird. Then run the migration tool against the new user.

6. Parallelize across workstations if you have them

   For estates over 10 mailboxes, parallelize by running Bridge on multiple workstations, each handling a different ProtonMail account at a time. Coordinate the user list so two workstations don't try to migrate the same account. This is the only way to meaningfully speed up large Workspace-to-Proton projects.

7. Verify each completed mailbox against baseline

   After each mailbox finishes, compare its ProtonMail item count against the Workspace baseline you captured. Variance under 1 percent is usually normal deduplication. Larger variance needs investigation: a delta run, or a manual check of the labels that lost messages.

8. Cutover MX records

   Once all mailboxes are verified, lower MX TTLs to 300 seconds 48 hours ahead. On cutover day, flip MX records to ProtonMail's MX endpoints. New mail starts landing in ProtonMail within minutes for fast DNS resolvers.

9. Run final delta per user

   After MX cutover, run a delta migration per user to catch any mail that arrived at Workspace during the cutover window. With Bridge already signed in for each user from the main migration, this should be a quick pass per mailbox.

Bridge stability tips#

The Bridge process is the single point of failure for the migration. A few things to keep it stable.

Run Bridge in foreground. Some users have reported Bridge stability issues when running as a background service for very long sessions. Foreground operation in a dedicated user session is more reliable.

Disable workstation sleep and screen lock. Bridge must stay running and reachable on localhost. Configure power settings to never sleep, disable screen lock, and disable any automatic logout policies if you're on a domain.

Don't run multiple Bridge instances on the same workstation. Bridge is designed to handle one account at a time. Running multiple instances causes port conflicts and unpredictable behavior.

Watch RAM usage. Bridge's RAM use grows with mailbox size. For a 50 GB mailbox, expect Bridge to use 1 to 2 GB of RAM. Make sure the workstation has headroom.

Restart Bridge between users. When switching from one ProtonMail account to the next, fully sign out of the first account and quit Bridge before signing into the next. This avoids stale state and reduces auth errors.

After cutover#

Standard cutover hygiene applies, with one ProtonMail-specific addition.

Switch users to ProtonMail clients. ProtonMail's web client, mobile apps, and Bridge are the supported access paths. For users who want to use a desktop client (Thunderbird, Outlook), they need Bridge running on their workstation. Plan a Bridge rollout in parallel with the migration cutover.

Forward Workspace to ProtonMail for 30 days. In Gmail per-user settings, configure forwarding to the ProtonMail address. Catches any stragglers.

Keep Workspace licensed for 60 days. Old contacts and services with stale MX records surface during the first months. The licensed Workspace is your forwarding origin and emergency fallback.

Archive Workspace before final shutdown. Use Google Takeout per user to export Gmail to MBOX before deleting accounts. Store on cold backup. Future requests for old mail will happen.

For the reverse direction, see ProtonMail to Gmail. If Office 365 is your alternative destination, Workspace to Office 365 covers that. The Workspace migration guide has more source-side context, and the complete email migration guide covers project management patterns.