PST, MBOX, and EML File Migration Guide

The CFO wants you to migrate ten years of email archives for a finance team that just moved to Microsoft 365. The archives are PSTs on a network share, MBOX files from someone's old Thunderbird install, and a folder of EML exports from a litigation hold five years ago. Nothing is on a live server. Nothing has a working IMAP endpoint. This is the project file-based migration was designed for, and it has a different rhythm than any live-server move.

When file-based migrations actually make sense#

The default for email migration is live-to-live — connect to source IMAP, push to destination, move on. File-based migration exists for the cases where that path isn't available, and recognising those cases early prevents weeks of wasted effort trying to force a live migration on data that doesn't live on a server anymore.

Archives from decommissioned systems#

The old Exchange server got turned off three years ago. Someone exported every mailbox to PST before pulling the plug. The PSTs have been sitting on a file share or an external drive ever since. Now someone wants the data searchable in the current platform. Live migration is not an option; the data isn't live.

Ex-employee mailboxes under retention#

When an employee leaves, their mailbox typically gets archived for some retention period (often 7 years in regulated industries). Keeping live mailboxes running for terminated users is expensive and licensing-heavy. The pattern is to export to PST or MBOX, store the file in a compliant location, and import it back if and when legal needs it. The employee offboarding mailbox archive playbook covers this lifecycle in detail.

Legal hold and eDiscovery#

Litigation holds often produce email file exports — usually PSTs from Microsoft 365 eDiscovery, sometimes EML collections from forensic tools. These get handed to lawyers, expert witnesses, or opposing counsel. Eventually they may need to come back into a mail system for further review.

Disconnected sources#

The source provider exposes only file exports, not IMAP. Some hosted webmail services, some government systems, and some niche compliance platforms only let you export, not connect. If you want the mail in a modern platform, you're going through files.

Pre-migration backup#

Even when live migration is available, some admins export everything to PST or MBOX as a belt-and-suspenders backup before the actual move. If the live migration fails midway, the files are the recovery path. The complete email migration guide treats this as an optional but recommended step for migrations where the source will be decommissioned after cutover.

Format differences#

PST, MBOX, and EML are three answers to the same question — how to store email on disk — and the differences shape what you can do with each.

PST: Outlook's native container#

Microsoft's Personal Storage Table format. A single binary file that contains an entire mailbox: folders, messages, attachments, calendar items, contacts, and tasks. Bound tightly to Outlook (and Microsoft 365 via import/export). The format has gone through generations: ANSI PST (legacy, 2 GB hard limit) and Unicode PST (modern, 50 GB practical limit). The PST file format glossary covers the structural details if you need them.

Strengths: rich metadata, includes non-mail PIM data, well-understood by Microsoft tooling, efficient for very large archives.

Weaknesses: vendor lock-in, limited cross-platform tooling, requires Outlook or a PST library to read. Corruption can render the whole file unreadable.

MBOX: the Unix-tradition format#

A flat text file that concatenates messages, with each message starting with a line beginning From . Used by Thunderbird (with variations), Apple Mail, Eudora (historical), Pine, and many Unix MTAs. The MBOX format reference goes into the variant landscape.

Strengths: plain text, portable, openable by basic tools, no vendor binding, easy to grep, easy to back up incrementally.

Weaknesses: no native folder hierarchy (one MBOX file per folder is the convention), no metadata beyond what's in message headers, variant fragmentation (mbox, mboxo, mboxrd, mboxcl, mboxcl2 — they're not all the same), and the From line delimiter can be confused with message content if not escaped properly.

EML: one message per file#

A single RFC 5322 message stored as a .eml file. Used by Outlook Express historically, Windows Mail, many forensic export tools, and pretty much any tool that wants to round-trip messages without committing to a container format. The EML format reference covers it briefly.

Strengths: maximum portability, every message is self-contained, trivial to script over, no corruption risk beyond the file itself, perfect for forensic and legal workflows.

Weaknesses: tens of thousands of files in a folder is unwieldy for filesystems and slow to enumerate. No folder structure information unless you encode it in directory names. Larger total disk footprint than container formats because of filesystem block overhead.

Choosing during a migration#

You usually don't choose — the source dictates the format. Outlook gives you PST. Thunderbird gives you MBOX (or several MBOX files, one per folder). Forensic tools give you EML. The migration tool needs to handle whatever the source produced.

File size limits and what happens at the edges#

Every format has size constraints. Some are technical, some are practical, all matter at the upper end of an archive migration.

PST size#

ANSI PST: 2 GB hard limit. If you have ANSI PSTs in your inventory, they are old (pre-2003 Outlook) and likely corrupt if anywhere near the limit. Convert to Unicode before migration, but accept that some content may already be lost.

Unicode PST: 50 GB technical limit, 20–25 GB practical limit before Outlook starts to feel slow opening the file. Microsoft's import tools accept files up to the technical limit, but on the destination side, an import of a 50 GB PST can take many hours and stress the destination tenant's throttling thresholds.

Strategy: split PSTs above 20 GB into multiple files before import. Date-range splits work well — one PST per year is a common pattern. The migrate PST to Microsoft 365 walkthrough covers the import side, including how to schedule large imports.

MBOX size#

No format-level limit. You can have a 100 GB MBOX file and it will technically work. In practice, anything over 5–10 GB starts to be painful — operations that need to read the whole file (search, repair, conversion) take linear time in file size, and a corrupt byte in the middle of a 20 GB MBOX can be hard to recover from.

Strategy: keep MBOX files under 4 GB where possible. Many tools that handle MBOX have implicit assumptions around 4 GB (32-bit file size assumptions from the format's history).

EML size#

Per-message size only. A single EML file can be as large as the message it represents (usually capped at 25–35 MB by the original sending server's limits, occasionally larger from legacy systems). The constraint isn't file size but folder enumeration speed.

Strategy: nest EMLs into directories by date or by sender to keep any single directory under 50,000 files. NTFS handles more but slows down; ext4 and APFS are more forgiving but UI tools (file managers, search indexers) get unhappy.

Corruption: the file-migration problem that lives migrations don't have#

Live IMAP migrations can fail in many ways, but mailbox corruption isn't usually one of them — the server is responsible for storage integrity. File-based migrations inherit the source filesystem's reliability. Files copied to a failing drive, files truncated by an interrupted export, files modified by antivirus software mid-migration — all of these are real problems.

Detection#

Open every file with a tool that validates its structure before you assume it's good. For PSTs, that means scanpst.exe (slow but thorough) or a third-party validator. For MBOX, it means parsing the file and confirming every message has a valid From separator and a parseable header block. For EML, it means parsing the headers and confirming the MIME structure.

Don't just check file size and modification date. Many corrupted files have plausible-looking metadata but unreadable internals.

Recovery#

For PST corruption, scanpst.exe handles structural issues. Severe corruption (header damage, truncation) requires specialised PST repair tools. Always operate on a copy of the file — repair tools can compound damage if they crash mid-repair.

For MBOX, the recovery story is gentler because the format is text. Even a partially corrupt MBOX can yield most of its messages to a tolerant parser. Many migration tools will skip-and-log unparseable regions rather than failing the whole file.

For EML, corruption is per-file, so you lose at most one message. The trade-off you accepted by using a one-file-per-message format.

When to give up#

If a PST is unreadable by scanpst and three separate repair tools, the content is probably gone. Document what was lost, get a sign-off if the data was under legal hold, and move on. The temptation to keep trying eats hours that should go to the messages that aren't corrupt.

Batch import strategies#

Importing hundreds of PST or MBOX files isn't a single operation — it's a campaign. Three patterns work.

Sequential per-mailbox#

Process one source mailbox completely (potentially several PSTs/MBOXes for one user's archives) before moving to the next. Easy to track, easy to recover from failure, slow. Use for small archives (under 50 files total) where you want maximum control.

Parallel by mailbox#

Process N source mailboxes in parallel, where N respects destination throttling. For Microsoft 365 destinations, start with 4–6 concurrent imports per tenant. For Gmail, similar. Faster than sequential, requires more monitoring, recovery from a partial failure is more complex.

Drive shipping (M365 specific)#

Microsoft accepts physical hard drives shipped to their data centers for very large PST imports. Useful when you have terabytes of PSTs and uploading over the network would take weeks. The catch is the encryption and chain-of-custody requirements; for most projects this isn't worth the setup overhead unless you're moving multiple TB.

Network upload (M365 specific)#

The standard import path — upload PSTs to an Azure storage container, then submit an import job that pulls from that container into target mailboxes. Throttled, but reliable, and the audit trail is good. Plan for 1–3 GB per hour per import job depending on time of day and tenant load.

Exporting from major sources#

The format you receive depends on what tool produced the export. Knowing the export patterns lets you predict what you'll be working with.

Outlook (desktop)#

Native PST export through File → Open & Export → Import/Export → Export to a file. Produces one PST per export operation. For multiple mailboxes (in a profile with several configured), each must be exported separately. Items are exported with full metadata.

Microsoft 365 (admin)#

eDiscovery and Content Search produce PST exports for targeted mailbox content. Whole-mailbox export is also available but requires careful permission scoping. The output is usually one PST per mailbox, sometimes split into multiple files for large mailboxes.

Thunderbird#

Stores mail as MBOX files natively. The on-disk path under the user's profile contains one MBOX per folder. ImportExportTools NG (a popular add-on) provides EML and other format exports for migration. The Thunderbird to Outlook migration walkthrough covers the specifics.

Apple Mail#

MBOX export via Mailbox → Export Mailbox. Produces one MBOX per selected folder, with subfolders nested in subdirectories. Apple's MBOX variant is mostly standard but has some subtle differences in line-ending handling that can trip up generic MBOX parsers. The Apple Mail to Outlook migration walkthrough goes into this.

Gmail (user)#

Google Takeout produces MBOX exports per label. One large MBOX per Takeout job, with messages tagged by their labels in the MBOX headers. Useful for personal backups, less useful for migration where you usually want label-to-folder mapping handled by a proper tool.

Forensic and legal-hold tools#

Typically produce EML collections, often with companion CSV or XML files describing custodian, source, and chain of custody. The migration tool needs to know how to preserve this metadata if the destination is going to maintain the chain of custody.

Importing into destinations#

Into Microsoft 365#

PST is the native import format. Use the Microsoft 365 admin center's import service (Network upload or Drive shipping) or PowerShell-driven imports for larger projects. MBOX and EML must be converted first, or fed in via a migration tool that handles the conversion as part of the import. The migrate PST to Microsoft 365 walkthrough has the detailed procedure.

Into Gmail / Google Workspace#

Google's Data Migration Service handles PSTs (it converts them under the hood). MBOX import is available through workspace admin tools or via IMAP-based migration tools that ingest MBOX and write to Gmail. EML can be imported by tools that handle single-message ingestion. The migrate MBOX to Gmail and migrate EML to Gmail walkthroughs cover the procedures.

Into Outlook (desktop)#

PST is native — open the file in Outlook and drag-and-drop or use Import wizard. MBOX requires conversion or a third-party plugin. EML can be opened individually or batch-imported with the right tool.

A sane approach to file-based projects#

The pattern that works: inventory everything before you import anything, normalise to one format internally if you can, run validation on every file, import in batches with explicit success/failure tracking per file, and produce a final report that reconciles source-file message counts against destination-mailbox counts.

The pattern that doesn't work: dragging a folder of PSTs into Outlook overnight and hoping. Outlook will sometimes silently skip corrupt items, partially import folders, or report success while only importing the first 80% of a file. Without explicit reconciliation, you won't know what's missing until a user goes looking for a specific message six months later.

For the broader project context — what to inventory, who needs to sign off, how to communicate the timeline — the complete email migration guide covers the surrounding workflow.