Migrate Office 365 to ProtonMail Through Bridge

You're moving from Office 365 to ProtonMail. The reasons vary: data sovereignty (Proton's Swiss jurisdiction), end-to-end encryption for future mail, escape from Microsoft's ecosystem, or simply a smaller per-user bill. The migration mechanics differ from a typical IMAP-to-IMAP move because ProtonMail's servers don't speak standard IMAP. Mail at rest is encrypted with keys derived from each user's password, and the destination side has to be ProtonMail Bridge running locally to handle the encryption translation. This guide covers the source prep, Bridge configuration, the actual migration, and the cutover.

Why ProtonMail Bridge changes the migration shape#

A normal IMAP migration tool fetches from a source IMAP server and appends to a destination IMAP server. ProtonMail's servers don't expose a standard IMAP interface to third-party clients because their mail content is encrypted with per-user keys.

ProtonMail Bridge is the answer. It's a local desktop application that you install on your workstation, sign into with the destination ProtonMail account, and then it presents a standard IMAP and SMTP server on 127.0.0.1. Conventional mail clients (Outlook, Thunderbird, Apple Mail) connect to Bridge. Migration tools do the same. Bridge handles the encryption transparently and relays to ProtonMail servers.

This has practical consequences. First, the workstation running Bridge has to stay awake and online for the entire migration. Second, Bridge handles one ProtonMail account at a time, so multi-user migrations are serial unless you have multiple workstations. Third, throughput is lower than direct IMAP because every message has to be encrypted client-side before upload.

Setting expectations#

Be clear about what moves.

Mail content moves cleanly. Headers, body, attachments, dates, read/unread state, and folder hierarchy come across through Bridge. Flagged state is preserved via IMAP's \Flagged keyword.

Outlook categories do not move. Bridge's IMAP interface doesn't expose Outlook's color category metadata. Plan to lose this. If categories matter for filing, export a list from Outlook before migrating in case you need to reconstruct.

Calendar, contacts, Teams, OneDrive do not move. This is a mail-only migration. ProtonMail Calendar and ProtonMail Contacts exist and support ICS and vCard import respectively, but those are separate migrations.

Encryption is at-rest, not end-to-end. Once messages land in ProtonMail through Bridge, they're encrypted with ProtonMail's standard at-rest encryption. They were not end-to-end encrypted in the source or in transit through Bridge. Historical email is not retroactively end-to-end encrypted.

Retention policies and labels are Microsoft-specific. Office 365 retention tags don't survive the IMAP copy. If retention is a compliance requirement, plan for that with an archiving tool separately.

Source-side preparation on Office 365#

The Microsoft side first.

Verify IMAP is enabled#

New Microsoft 365 tenants ship with IMAP disabled. Sign into the Microsoft 365 admin center as an admin, go to Active users → [user] → Mail → Manage email apps, and confirm IMAP is checked. If it's off, enable it and wait about 15 minutes for the change to propagate before testing.

Generate app passwords or configure OAuth2#

If MFA is enabled (it should be), basic auth requires app passwords. Generate at mysignins.microsoft.com/security-info per user. Alternatively, if your migration tool supports OAuth2 against Microsoft, that's cleaner for multi-user projects because you don't need per-user password generation.

For more on why app passwords are needed at all, see the app passwords explainer.

Capture a baseline#

Before any data moves, dump per-mailbox stats. From Exchange Online PowerShell:

Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics |
  Select DisplayName, ItemCount, TotalItemSize |
  Export-Csv -Path .\baseline.csv -NoTypeInformation

Save this. You'll compare against it to verify each migration.

Note Office 365's IMAP host#

outlook.office365.com:993 SSL. Username is the full email address. Password is either the regular password (if MFA off) or the app password (if MFA on).

For broader context on the source side, the Office 365 migration guide covers prep in depth.

ProtonMail and Bridge setup#

The destination side.

Provision ProtonMail accounts#

Sign up for ProtonMail for Business or use existing accounts. Verify domain ownership via DNS records. Create users matching every Office 365 user being migrated. Allocate storage: ProtonMail Plus is 15 GB per user, ProtonMail Business is 500 GB pooled.

Install ProtonMail Bridge#

Download Bridge from proton.me/mail/bridge. Install on the workstation running the migration. Bridge runs as a system tray app 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. Bridge generates a Bridge-specific IMAP/SMTP password (different from the ProtonMail account password). Note the local IMAP host and port, typically 127.0.0.1:1143 for IMAP and 127.0.0.1:1025 for SMTP. Bridge supports STARTTLS on these ports.

Verify Bridge connectivity#

Before involving the migration tool, test Bridge with Thunderbird. Add an account with host 127.0.0.1, port 1143, STARTTLS, username being the full ProtonMail email, password being the Bridge-generated one. Confirm folders list (Inbox, Sent, Drafts, Spam, Trash, Archive, plus any existing labels). Append a test message and confirm it shows up in the ProtonMail web interface.

If you hit Bridge connection issues, see fix ProtonMail Bridge connection.

Step-by-step migration#

1. Confirm Bridge is healthy

   With Bridge signed in for the first ProtonMail account, verify Bridge's status indicator shows the account connected (no errors). Use Thunderbird to confirm you can list folders and append a test message via the local IMAP endpoint. Don't proceed until this is clean.

2. Confirm Office 365 IMAP credentials work

   Before involving the migration tool, verify Office 365 credentials. In Thunderbird, add an account with host outlook.office365.com, port 993, SSL, full email as username, regular password or app password as appropriate. Confirm folders list. If you get AUTHENTICATIONFAILED, fix it before going further.

3. Connect both sides in Mailbox Taxi

   Add Office 365 as the IMAP source with the verified credentials. Add Bridge as the IMAP 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 and show side-by-side mapping.

4. Map system folders

   Office 365's system folders are Inbox, Sent Items, Drafts, Junk Email, Deleted Items, Archive. ProtonMail's are Inbox, Sent, Drafts, Spam, Trash, Archive. Map Sent Items to Sent, Deleted Items to Trash, Junk Email to Spam (or exclude Junk Email entirely). User folders carry over with hierarchy preserved.

5. Run a single pilot mailbox

   Pick a mid-sized mailbox (5 to 10 GB) with reasonable folder complexity. Migrate it to completion. Then open ProtonMail webmail and verify: dates correct, attachments open, folder structure preserved, no obvious duplicates. Fix configuration and rerun until clean.

6. Switch Bridge to the next user and repeat

   Bridge handles one ProtonMail account at a time. For each new user: sign out of Bridge, sign in with the next ProtonMail account, wait for initial sync (a few minutes), verify connectivity with Thunderbird, then run the migration tool against the new mailbox pair.

7. Parallelize across workstations for larger estates

   For estates over 10 users, run Bridge on multiple workstations in parallel, 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 meaningful way to speed up large Office 365 to ProtonMail projects.

8. Verify each completed mailbox

   After each mailbox finishes, compare its ProtonMail item count against the Office 365 baseline. Variance under 1 percent is usually genuine deduplication. Larger variance needs investigation: a delta run, or manual check of which folders lost messages.

9. Cutover MX records

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

10. Run final delta per user

    After MX cutover, run a delta migration per user to catch mail that arrived at Office 365 during the cutover window. With Bridge already signed in for each user, this is a quick pass.

Bridge stability and throughput#

Bridge's stability is the single point of failure. A few practical notes.

Run Bridge in foreground in a dedicated user session. Some users report background-service mode being less stable for long sessions. Foreground in a dedicated session is more reliable.

Disable workstation sleep, screen lock, and automatic logout. Bridge has to stay running on localhost for the entire migration. Any interruption stalls things.

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

Restart Bridge between users. When switching accounts, fully sign out of the first and quit Bridge before signing into the next. Avoids stale state and reduces auth errors.

Bridge auth errors usually mean session expiry. Long sessions sometimes hit a refresh limit. Sign out and back in inside Bridge to refresh, then resume the migration.

Throughput-wise, expect 1 to 3 messages per second to Bridge with reasonable concurrency. That's about 5,000 to 10,000 messages per hour. Plan a 30 GB mailbox to take 30 to 50 hours.

After cutover#

The technical migration is done; the cutover sequence matters.

Forward Office 365 to ProtonMail for 30 days. In Outlook on the web per user, configure forwarding to the ProtonMail address. Catches anything that lands at Office 365 despite MX changes.

Configure ProtonMail Bridge for end users. If users want to use desktop clients (Outlook, Apple Mail, Thunderbird) with ProtonMail, they need Bridge installed and running on their workstation. Plan a Bridge rollout in parallel with the migration cutover. Most users can use ProtonMail web and mobile clients without Bridge.

Keep Office 365 licensed for 60 days. Don't cancel immediately after cutover. Old contacts and services with stale MX records surface during the first month or two. Licensed Office 365 serves as your forwarding origin and emergency fallback.

Archive Office 365 before final shutdown. Export each mailbox to PST via the Exchange admin center compliance search or eDiscovery export. Store on cold backup. Future requests for old mail will happen.

For the reverse direction, ProtonMail to Office 365. If you're considering Workspace instead, Workspace to ProtonMail covers a similar shape. The Office 365 migration guide has source-side depth, and the complete email migration guide covers project sequencing.

Common errors#

AUTHENTICATIONFAILED from Office 365: IMAP disabled at the mailbox level, basic auth blocked at tenant level, or wrong credentials. Generate an app password or use OAuth2.

AUTHENTICATIONFAILED from Bridge: you used the ProtonMail account password instead of the Bridge-generated IMAP password. Open Bridge, copy the IMAP password from the account details, and use that.

Connection refused to 127.0.0.1:1143: Bridge isn't running, or it crashed. Open Bridge, sign in, wait for initialization, then retry.

Too many simultaneous connections from Bridge: Bridge limits concurrent connections from a single client. Lower your migration tool's concurrency to 2 or 3.

Message too large for destination: ProtonMail's per-message limit through Bridge is around 25 MB. Save large attachments separately and re-import without the attachment.

OAuth2 token expired (when using OAuth against Office 365): your migration tool's session token has expired. Re-authenticate and resume.