Microsoft will introduce a new Azure PST Import experience in Exchange Online through a staged migration workflow, with a public preview targeted for September 2026 and general availability targeted for October 2026. The feature allows organizations to import PST files already stored in Azure Blob Storage directly into Exchange Online mailboxes using an analysis-first, two-step migration batch process that separates validation from execution. It is listed under Microsoft 365 Roadmap ID 557559 and is in development for worldwide standard multi-tenant environments.
The move represents a significant operational upgrade from the existing Purview network upload model, which often forces administrators to juggle temporary uploads, mapping CSVs, and last-minute data-quality surprises. By aligning PST imports with the Exchange Migration Service’s familiar endpoint-and-batch pattern, Microsoft is giving IT teams a more controlled, repeatable way to bring legacy email archives into managed Microsoft 365 governance.
How the New Azure PST Import Works
Unlike the current Microsoft 365 Import service—where you obtain a SAS URL, upload PST files to Microsoft-provided temporary storage, map each file to a mailbox via CSV, and then run a single import job—the upcoming Azure PST Import experience leverages your own Azure Blob Storage container as a persistent, governed staging area. The workflow then splits the process into two distinct phases.
Step 1: Analysis-only batch
You create a migration endpoint that authenticates to your Azure Blob Storage, then launch an analysis batch that inspects every PST file without moving a single message into any mailbox. The service examines file integrity, item counts, date ranges, message types, and potential compliance flags. It surfaces corrupted files, oversized archives (Microsoft recommends keeping PSTs under 20 GB for best performance), folder hierarchies deeper than 300 levels, and individual messages larger than 150 MB—all of which can derail an import. This checkpoint lets you clean up, repair, or exclude problematic data before it ever touches a user’s mailbox.
Step 2: Final migration batch
Armed with the analysis report, you configure the actual import. You decide which PSTs to proceed with, which mailboxes (primary, archive, or inactive) they should land in, and whether to apply any date-based or message-type filters. Because the analysis already flagged skip-worthy items, you can set precise scope rules—for example, importing only messages from the last seven years or excluding known personal folders. Then you trigger the migration batch, and Exchange Online begins ingesting data at roughly 24 GB per mailbox per day (though Microsoft warns that actual throughput varies).
This two-stage design is a deliberate break from the old “upload and hope” approach. It forces a governance checkpoint: before any PST content can alter a production mailbox, the organization must review exactly what’s inside each file.
Why This Matters for Your Organization
PST files are the digital equivalent of dusty filing cabinets: they hold years of business correspondence, contractual evidence, and sometimes sensitive personal data, scattered across file servers, departed employees’ laptops, and shared departmental drives. Bringing that content into Exchange Online is technically possible today, but the process has long been one of the more brittle corners of Microsoft 365 migration work. The new Azure PST Import aims to fix three pain points:
1. Tighter separation of validation and execution
With the current network upload method, analysis happens after you’ve already uploaded everything and prepared your mapping file. If the analysis reveals that half your PSTs are corrupt or mapped to the wrong people, you’ve already spent time and storage. The coming workflow runs analysis as a standalone batch, so you can iterate on your source data without affecting live mailboxes.
2. A familiar migration-batch model
Exchange admins already manage mailbox moves, tenant-to-tenant transitions, and G Suite migrations through migration endpoints and batches. Azure PST Import plugs right into that operational muscle memory. You get batch-level monitoring, status reporting, and the ability to pause or adjust scope—something the legacy Import service doesn’t offer.
3. Governance-first ingestion
When a PST is imported into Exchange Online, Microsoft automatically places the target mailbox on an indefinite retention hold to prevent old messages from being instantly deleted by active retention policies. While that safeguard exists today, the analysis-first workflow makes it easier to decide what retention label or policy should apply post-import. Instead of reacting after the fact, you can plan during the analysis phase which data belongs under which lifecycle rule.
For eDiscovery and compliance teams, the benefit is even clearer. PST files sitting on unmanaged file shares are invisible to Microsoft 365 search tools. Importing them into Exchange Online—once validated—brings historical records under centrally managed legal holds, audit logging, and insider-risk detection. But the flip side is that importing without a plan can create a compliance mess. The analysis batch helps you answer: Should this ten-year-old archive be placed in an active user’s mailbox where it might be subject to a new litigation hold? The tool won’t make the decision for you, but it will give you the data to make it.
What to Do Between Now and the Preview
Microsoft’s roadmap gives you roughly a year before the public preview. That’s not idle time; it’s a window to get your PST estate in order.
Inventory everything
Locate every PST file across file shares, endpoint backups, legacy archive repositories, and user profiles. Note the file size, last-modified date, suspected owner, and any compliance flags (e.g., HR data, legal matters). Treat this as a discovery effort: you can’t migrate what you don’t know about.
Clean up and normalize
Use Microsoft’s own Scanpst.exe tool to repair corrupted files now. Split any PST larger than 20 GB into smaller archives, flatten deeply nested folders, and identify encrypted or password-protected files that will block ingestion. If you can, standardize naming conventions so mapping files can be built more easily later.
Build mailbox mapping decisions
Not every PST should go to an active user’s primary mailbox. Some will be better placed in archive mailboxes (to avoid consuming primary mailbox quota) or inactive mailboxes (for departed employees). Microsoft’s current PST import service already supports these targets; the new workflow will likely carry forward that flexibility. Start the conversation with legal, HR, and records management about who should receive what—and what should perhaps not be imported at all.
Plan a pilot
Once the preview arrives, don’t throw your entire archive estate at it on day one. Choose a small, representative set of files—a clean PST, a borderline-large one, a mapped archive mailbox, and one that needs filtering. Run the analysis batch, study the output, then execute the final batch. Measure throughput, note any throttling, and document exceptions. This will give you a repeatable template when GA hits in October 2026.
Review your retention architecture
Because imported PSTs can instantly become subject to your existing retention labels and policies, now is the time to audit those settings. Does your default retention label delete items older than seven years? If so, a PST full of ten-year-old emails could vanish shortly after import unless you deliberately place the mailbox on hold. Work with your compliance team to define a post-import retention strategy before the data lands.
The Road Ahead
Azure PST Import is not a magic wand—corrupt files will still fail, throughput will still be limited by mailbox ingestion rates, and no tool can replace thoughtful governance. But the move to an analysis-first, migration-batch-driven model is the most significant improvement to Microsoft 365 PST handling in years. It acknowledges that PST migration is as much a compliance decision as a technical one, and it gives administrators the breathing room to make that decision with data rather than instinct.
Keep an eye on the Microsoft 365 Roadmap entry for ID 557559. Specific endpoint configuration details, PowerShell cmdlet support, and licensing requirements will only surface when preview documentation ships. For now, the smart move is to prepare your source data, establish your governance rules, and be ready to test the moment the preview lights up.