If you’ve ever had to deal with PST files, you’ll know they have a habit of appearing at exactly the wrong time.
Old Outlook archives. Historical mailboxes. Former employees. Data sitting on file shares or someone’s laptop. And eventually someone asks the inevitable question:
“Can we get all of this email back into Microsoft 365?”
Microsoft is introducing Azure PST Import, providing administrators with a structured, PowerShell-based way to import PST files stored in Azure Blob Storage directly into Exchange Online mailboxes.
The new capability is designed to make the process more controlled and auditable, while adding an important step that administrators will appreciate:
You can analyse and validate the import before actually importing the data.
That’s a potentially significant improvement when you’re dealing with large quantities of historical email.
☁️ So, what is Azure PST Import?
At its simplest, Azure PST Import provides a way for administrators to take PST files stored in Azure Blob Storage and import their contents into Exchange Online mailboxes.
The process is administrator-driven and uses PowerShell cmdlets rather than a graphical user interface.
The basic workflow looks like this:
Azure Blob Storage → Analyse → Validate → Import → Report → Clean up
The idea is to provide administrators with greater confidence before the data actually lands in users’ mailboxes.
And when you’re dealing with historical email data, that’s a very useful capability.
🔍 Analyse first, import second
One of the more interesting aspects of the new experience is the Analyze mode.
Rather than immediately starting an import and discovering problems halfway through, administrators can first run a migration batch in Analyze mode.
This allows Microsoft 365 to validate the readiness of the import.
For example, the analysis can validate things such as:
- Whether the specified PST files actually exist
- PST file sizes
- Whether the target mailbox is suitable
- Whether the appropriate licence is assigned
- Whether the mailbox is inactive or soft-deleted
- Whether the recipient type is UserMailbox
- Whether an archive is enabled when importing to an archive
- Relevant mailbox quota requirements
That’s an important change in mindset.
Instead of:
“Let’s start the migration and see what happens.”
You can take the approach of:
“Let’s validate everything first.”
🛠️ How does the process work?
The process is essentially broken into several stages.
1. Create the Azure PST Import endpoint
The first step is establishing the connection between Azure storage and Exchange Online.
Administrators create an Azure PST Import migration endpoint using PowerShell.
The endpoint setup also validates that the Azure storage account and container exist and are reachable.
There’s an important permission requirement here.
The Office 365 Import Service application needs the:
Storage Blob Data Reader
role on the target Azure storage account.
Without that permission, endpoint creation will fail.
So this is something worth checking before you start troubleshooting the migration itself.
2. Prepare your import files
You’ll need to prepare your batch input files, using XML and/or CSV, depending on the requirements of your import.
These files provide the information required to tell the service what should be imported and where it should go.
This is another area where preparation matters.
A little time spent getting your input files right can save considerably more time later.
3. Run the migration in Analyse mode
This is arguably the most useful part of the new workflow.
Rather than immediately importing the PST data, run the migration batch in:
Analyze
mode.
Microsoft can then validate the import and provide analysis results and reports.
This gives administrators the opportunity to identify potential problems before the actual import begins.
4. Review the results
Once analysis is complete, administrators can review the results and reports.
This is your opportunity to stop and fix anything that isn’t quite right.
Perhaps a mailbox doesn’t meet the requirements.
Perhaps a PST file isn’t where you expected it to be.
Perhaps a quota isn’t sufficient.
Perhaps the target mailbox isn’t in the correct state.
Whatever the issue, the idea is to discover it before starting the real import.
5. Create and start the import batch
Once you’re happy with the analysis results, you can use those results to create and start the actual import batch.
At that point, the PST files are imported into the specified Exchange Online mailboxes.
The process is controlled by administrators through PowerShell.
There is currently no graphical user interface for this experience.
🧹 And then comes the clean-up
Once the import has completed, administrators can perform the required post-import clean-up.
This is worth considering as part of the migration plan rather than treating it as an afterthought.
PST files have a habit of multiplying.
If you’ve ever discovered a folder containing:
Archive.pst
Archive-old.pst
Archive-final.pst
Archive-final-2.pst
Archive-final-REALLY-FINAL.pst
…you’ll understand why.
A structured import process gives organisations an opportunity to bring historical email into a more manageable Microsoft 365 environment.
🔐 What does this mean for compliance?
This is where Azure PST Import becomes particularly interesting from a Microsoft Purview and governance perspective.
Once PST content has been imported into Exchange Online, it becomes part of the mailbox environment.
That means the imported data is then subject to the existing behaviours and controls associated with the target mailbox.
According to Microsoft’s announcement, imported mailbox data becomes subject to existing:
- Microsoft Purview retention policies
- Retention labels
- Holds
- Deletion workflows
That could be particularly valuable for organisations that have historically had important business records sitting inside unmanaged PST files.
Instead of having historical information isolated inside individual PST files, the data can be brought into the Microsoft 365 environment where existing governance processes can apply.
🧾 What about auditing?
The change also provides administrators with existing audit and reporting capabilities.
Administrative activity relating to the PST import, along with resulting mailbox changes, can be monitored using existing:
Exchange Online audit logging
and
Microsoft Purview audit capabilities.
This is important from a compliance perspective because organisations don’t simply need to move data.
They may also need to demonstrate:
What was imported?
When was it imported?
Who performed the activity?
What happened to the data afterwards?
Being able to monitor the process using existing audit and reporting mechanisms helps support that requirement.
👥 Who is this relevant to?
This update is particularly relevant to:
- Microsoft 365 administrators
- Exchange Online administrators
- Organisations managing historical PST archives
- Organisations importing PST data into user mailboxes
- Organisations importing PST data into archive mailboxes
- Teams responsible for Microsoft Purview Data Lifecycle Management
There is no direct user action required.
This is an administrator-driven process.
⚠️ There are some important prerequisites
Before jumping straight in, administrators should make sure the environment is ready.
You’ll need:
Azure storage
Your Azure storage account and container need to exist and be reachable.
Azure permissions
The Office 365 Import Service needs the Storage Blob Data Reader role on the target storage account.
Import files
Your XML and/or CSV batch input files need to be prepared correctly.
Mailbox readiness
The target mailbox needs to meet the required conditions.
That includes checking:
- Appropriate licensing
- Mailbox status
- Recipient type
- Archive status, where applicable
- Archive quota
- Recoverable Items quota
PST readiness
The PST files themselves also need to be checked.
Analysis validates that the specified PST files exist and validates their file size.
🧠 Why is this interesting from a governance perspective?
For me, the most interesting part of this isn’t actually the PST import itself.
It’s what happens after the PST is imported.
PST files have traditionally been a bit of an information governance headache.
They can contain years of email.
They can exist outside the normal Microsoft 365 governance framework.
They can be difficult to discover.
They can be difficult to manage consistently.
And they can sit quietly on a laptop or file share for years.
Moving that information into Exchange Online changes the conversation.
Once imported, the data becomes part of the Microsoft 365 environment and can fall under the organisation’s existing retention, hold, deletion and auditing processes.
In other words:
The goal isn’t just to move old email.
It’s to bring that information into a governed environment.
And that’s a much more interesting proposition.
🚀 What should administrators do now?
If your organisation has a significant PST estate, this is worth putting on the radar.
I’d start by asking a few simple questions:
How many PST files do we actually have?
Where are they?
Who owns them?
What information do they contain?
Do they contain records that need to be retained?
Are any subject to legal or regulatory requirements?
Which mailboxes should they ultimately belong to?
Do our current retention policies apply appropriately to the target mailboxes?
Those questions turn a technical migration into an information governance exercise.
And that’s exactly how I would approach it.
📅 When is it coming?
Microsoft says the global rollout is expected to:
Begin: Late August 2026
Complete: Early September 2026
Microsoft 365 Roadmap ID: 565865
The experience is PowerShell-only and isn’t currently being delivered through a graphical administration interface.
💡 The Jim Talks takeaway
PSTs aren’t going away overnight.
But perhaps we can finally start moving away from the idea of treating them as mysterious containers of historical email sitting somewhere on a network drive.
Azure PST Import gives administrators a structured path for bringing that information into Exchange Online.
And the really important part isn’t simply the ability to import it.
It’s the ability to analyse first, validate the destination, import in a controlled way, audit the activity and then bring that historical information under the organisation’s existing Microsoft 365 governance processes.
Because ultimately:
Moving information is migration.
Bringing it into a governed environment is information governance.
And that’s where this update gets interesting.
Leave a Reply