Migrate Thunderbird to Office 365: MBOX to Exchange Online

Microsoft 365 has a clean import story for PST and a clean import story for IMAP-backed source servers. It has no story at all for MBOX, which is unfortunate because Thunderbird is one of the more common mail clients still in serious business use, especially among engineering teams and Linux shops. To move a Thunderbird user to Exchange Online you have to bridge the gap yourself — either by uploading MBOX content over IMAP to the user's new mailbox, or by converting MBOX to PST and feeding it to Microsoft 365's import service.

Two viable paths, neither obvious#

The Microsoft 365 admin centre exposes two import paths under the Information Governance area. Network Upload accepts PST files into an Azure storage location and ingests them into target mailboxes. Drive Shipping does the same with a physical drive. Neither accepts MBOX. The Exchange admin centre offers IMAP migration batches, but those move from a remote IMAP server, not from local files. None of the built-in tooling sees a Thunderbird profile on a user's laptop.

That leaves you with two real choices.

Path A: IMAP upload to the user's Microsoft 365 mailbox. A desktop migration tool reads MBOX from the profile and APPENDs each message to outlook.office365.com over IMAP. Simple, works for any mailbox size in theory, but constrained by Exchange Online IMAP throttling at scale.

Path B: MBOX to PST conversion, then Microsoft 365 Network Upload. Convert each MBOX to a PST file, upload to Azure storage with AzCopy, then map PSTs to target mailboxes via a CSV. Faster for large mailboxes and for many mailboxes at once, but adds a conversion step and burns disk space.

Pick A when you have under 5 GB per mailbox and fewer than ten mailboxes. Pick B when you have more.

The rest of this post focuses on Path A because that is what most Thunderbird migrations end up using. If you need the PST route, see the Office 365 migration guide for Network Upload details and pair it with a separate MBOX-to-PST conversion step.

Thunderbird profile preparation#

The source side is the same regardless of which destination you pick.

Find the profile#

Help > Troubleshooting Information > Open Folder next to Profile Folder. The profile typically lives at %APPDATA%\Thunderbird\Profiles\<random>.default-release on Windows, ~/Library/Thunderbird/Profiles/<random>.default-release on macOS, and ~/.thunderbird/<random>.default-release on Linux.

Inside, the message stores are under Mail/ and ImapMail/. Each Thunderbird folder is a single MBOX file with no extension, accompanied by an .msf index that you can ignore.

Compact, then snapshot#

Right-click each account and choose Compact Folders. Wait until Thunderbird stops chewing. Deleted messages are still on disk in MBOX form until you compact, and they will slow down both upload and PST conversion. Compaction can reduce a heavy mailbox by 30–50%.

Then close Thunderbird and copy the entire profile folder to a backup drive. This is your rollback path. Every Thunderbird migration deserves a snapshot first, full stop.

Inventory what you have#

Make a list per mailbox of folder names and approximate MBOX sizes. The total tells you whether Path A or Path B is the right call. The folder list tells you whether any contain non-ASCII characters that will need mapping during upload.

Microsoft 365 destination setup#

Exchange Online IMAP is the destination protocol for Path A.

Enable IMAP on the mailbox#

By default new Microsoft 365 mailboxes have IMAP enabled, but some tenant baselines disable it. Confirm in the Exchange admin centre under Recipients > Mailboxes > the target user > Manage email apps. IMAP should show as enabled. If not, switch it on.

Sort out authentication#

This is where most Thunderbird-to-365 migrations stall. Microsoft 365 has been progressively disabling basic auth, and most tenants now require OAuth2 for IMAP.

Two options:

OAuth2 with an Azure AD app registration. Register an app in Azure AD with the IMAP.AccessAsUser.All delegated permission. Your migration tool runs the OAuth flow once and gets a refresh token. This is the right answer for ongoing or multi-user migrations.

App password. If the user has MFA enabled and your tool does not support OAuth2, generate an app password under the user's My Account > Security info. App passwords are 16-character strings. They bypass MFA, so they are not ideal but they work.

For a fleet migration, a third option is using a service account with ApplicationImpersonation rights, but that approach is being phased out across Microsoft 365 tenants. Stick with OAuth2 where possible.

The app password walkthrough covers Microsoft-specific app password generation.

Check conditional access#

Conditional access policies routinely block IMAP traffic. Check the CA policies in the Microsoft Entra admin centre under Protection > Conditional Access. Any policy that:

• Requires compliant devices and applies to all cloud apps
• Blocks legacy authentication
• Requires app-enforced restrictions

will likely block your migration tool unless you exempt either the user, the migration service principal, or the IP range you are running the tool from.

The migration itself#

1. Stage the source

   Either copy the Thunderbird profile to a stable migration server, or run the migration tool on the user's machine if it can read MBOX directly. Mailbox Taxi runs desktop-first and reads the profile in place, which is convenient for one-off Thunderbird migrations.

2. Connect Microsoft 365 with OAuth2

   Point the tool at outlook.office365.com:993 with TLS. Authenticate using the Azure AD app registration. Test with a one-message dry run before scaling up.

3. Map Thunderbird folders to Exchange folders

   Inbox to Inbox, Sent to Sent Items, Drafts to Drafts, Trash to Deleted Items, Junk to Junk Email. Local Folders content typically goes under a parent folder like Archive/Thunderbird. Non-ASCII folder names need to be mapped to ASCII equivalents if your tool does not handle UTF-7 cleanly.

4. Pilot one full mailbox

   Migrate one user end to end. Verify message counts, dates, read/unread flags, attachments, and that nested folders nest correctly. Fix any issues before the bulk run.

5. Run the bulk migration overnight

   Cap parallelism at two to three connections per mailbox and around five mailboxes concurrently. Exchange Online will throttle aggressively if you push past this. Set the run to start at 18:00 local and check it in the morning.

6. Verify and cut over

   Compare per-folder counts. Spot-check ten messages per user. Reconfigure Outlook desktop and Outlook on the web to the new mailbox. Decommission Thunderbird account profiles on user machines.

Throughput and throttling#

Realistic Exchange Online IMAP throughput sits at 80–120 MB per minute per connection. Microsoft does not publish hard byte limits the way Gmail does, but the practical ceiling shows up as Too many simultaneous connections, Server unavailable, or simply long stalls when you push too hard.

Plan around:

• Two to three IMAP connections per mailbox maximum
• Five to ten mailboxes concurrent across the tenant
• A roughly 90-minute window per 5 GB of mailbox content
• Rate-limit recovery times of 5–15 minutes when throttled

If the bulk run hits a throttle wall, the right move is to stop, wait an hour, lower parallelism, and resume. Pushing harder makes the tenant-wide rate limit window longer for every user.

Errors worth recognising#

AUTHENTICATIONFAILED — token expired or basic auth disabled. Reauthorise via OAuth2.

Too many simultaneous connections — drop parallelism, wait, retry.

Message too large for destination — Exchange Online accepts up to 150 MB by default but tenants can lower this. Increase the tenant's MaxSendSize and MaxReceiveSize if you have admin rights, or skip the offending messages.

Folder UTF-7 conversion error — folder name has characters your tool encodes wrong. Rename the source folder to ASCII.

OAuth2 token expired — your tool should auto-refresh. If not, restart the run with fresh credentials.

STARTTLS handshake failed — usually a corporate proxy intercepting TLS. Run the migration from an unproxied network or whitelist outlook.office365.com.

Verification#

A Thunderbird-to-365 migration is not done until verification passes.

Compare folder counts between Thunderbird and the destination mailbox in Outlook on the web. Counts should match within a small margin (a few messages can differ due to MAPI vs IMAP visibility of system items).

Spot-check ten messages per major folder. Open them in Outlook and confirm:

• Date and time matches the original
• Read/unread flag matches
• Attachments open
• HTML body renders correctly
• Special characters in subject and body display correctly

Check message threading. Outlook threads on In-Reply-To and References headers, which IMAP APPEND preserves if your tool is sane.

Run an Exchange Online search for a known recent migrated sender to confirm the mail is reachable through search, not just visible in the folder tree.

After the cutover#

Configure Outlook on each user machine. Modern auth signs the user in via the corporate identity provider, so they should not have to enter a password for the new account.

Filters do not migrate. Rebuild as Outlook rules in either the desktop client or in Outlook on the web. Most Thunderbird filter conditions map cleanly to Outlook's "From," "Subject contains," and "To or Cc" conditions.

Address books export as LDIF or CSV from Thunderbird and import into Outlook contacts or directly into Exchange Online via PowerShell for tenant-wide directories.

Calendars are an ICS export from Thunderbird's Lightning calendar and an Outlook calendar import.

Decommission Thunderbird account profiles on user machines once everyone is confirmed working in Outlook. Leave the application installed for two weeks so users can read the local snapshot if they need to verify something.

When the other guides apply#

If the destination is Outlook.com (consumer) rather than Microsoft 365 (business), see migrate Thunderbird to Outlook. The IMAP host differs and the auth model is simpler.

If the destination is Gmail or Google Workspace, migrate Thunderbird to Gmail covers the label-mapping concerns specific to Google's data model.

If you have already converted MBOX to PST and want to use Microsoft 365 Network Upload directly, the Office 365 migration guide covers the PST import process in detail, and migrate MBOX to Office 365 covers the upload step in isolation.

The MBOX format glossary entry explains the framing details that some uploaders mis-parse, which is worth a read if your pilot shows truncated messages.