Need to Restore PST Files to Office 365 Mailboxes - What's the Best Approach

For a one-time PST restoration into existing Microsoft 365 mailboxes, Microsoft Purview is usually the first option I would evaluate because it keeps the import, compliance roles, and destination tenant in one Microsoft-managed workflow. If this is a recurring migration project, involves many tenants, or needs a service provider to manage complex batch work, a paid platform such as BitTitan MigrationWiz can be worth comparing.

The difference is not simply free versus paid. Purview may be the better choice when the main concern is governance and you can accept the setup and role requirements. MigrationWiz may reduce operational effort for a large, repeatable project, but it adds licensing cost and another vendor to the process. In either case, run a pilot mailbox, validate folder mapping and date ranges, and retain the source PSTs until users confirm the restored data.

A few things worth knowing before you pick a tool, because the native import service has documented behaviours that affect your data consistency concern more than the tool choice will.

ON PERMISSIONS

The native import does not require broad admin rights. It needs two Exchange Online roles, Mailbox Import Export and Mail Recipients. Mailbox Import Export is not assigned to any role group by default, not even Organization Management, which is why it feels like a hurdle. The documented guidance is to create a dedicated role group containing just those two roles and add the person running the import. That is narrower than Global Administrator, and it is worth comparing honestly against the third party route, which typically needs application permissions or impersonation rights that persist across every mailbox in the tenant for as long as the app registration exists.

A temporary, purpose built role group is usually less standing privilege than a permanent app registration with mailbox wide access.

https://learn.microsoft.com/purview/pst-import-overview 

ON LARGE PST FILES

Keep each file at or below 20 GB. Above that the documentation says performance is affected, and the troubleshooting article names oversized files as the first thing to check when a job appears stuck.

Expect roughly 24 GB per day per mailbox, and that rate is not guaranteed. Multiple PSTs going into the same mailbox import sequentially, while PSTs going to different mailboxes import in parallel. If you are working to a deadline, spread the work across mailboxes rather than splitting one mailbox into many files.

https://learn.microsoft.com/troubleshoot/microsoft-365/purview/pst-import-service/issues-with-pst-import-job 

ON RESTORING ONLY CERTAIN FOLDERS

The import service does not filter folders inside a PST, but you do not need a third party tool for this either. Open the PST in Outlook, export only the folders you want into a new PST, and import that one. It is tedious across many users, but it is free, it needs no additional privilege, and you keep a copy of exactly what you imported.

Note that the TargetRootFolder parameter in the mapping file controls where content lands inside the target mailbox, not which source folders are included. It is useful for keeping a restore separate from live mail, not for filtering.

ON DATA CONSISTENCY, WHICH IS WHERE I WOULD PUT THE ATTENTION

Three documented behaviours matter more here than tooling.

Items larger than 150 MB are skipped and not imported, because that is the Exchange Online message size limit. Not failed, skipped. If you need to demonstrate completeness afterwards, know that this gap exists by design.

If the PST contains an item larger than 35 MB, the import service automatically raises MaxReceiveSize on the target mailbox to 150 MB. That is a permanent change to mailbox configuration made as a side effect of a restore. Check afterwards with Get-Mailbox user | FL MaxReceiveSize if that matters in your environment.

After import, retention hold is turned on indefinitely on the target mailbox. This is deliberate, so that old imported mail is not immediately purged by an existing retention policy. It also means your retention policy stops processing that mailbox until someone turns the hold off. If you operate under a documented retention schedule, that is a gap you have opened and should close deliberately rather than discover later.

Also worth knowing: PSTs cannot be imported to public folders, and a PST with 300 or more levels of nested folders will not import at all.

https://learn.microsoft.com/purview/pst-import-network-upload 

ONE PRACTICAL NOTE ON THE UPLOAD

AzCopy is the only supported upload method, and you point it at a directory rather than at a file. Everything in that source location is uploaded, so stage only the PSTs you actually intend to import.

Whichever route you take, test on a single mailbox first, then check MaxReceiveSize and the retention hold state before doing the rest.

For large-scale PST restores with selective folder needs, Microsoft's native Purview import service tends to fall short, it's mostly all-or-nothing, doesn't give much visibility into what happened at the item level, and needs fairly broad admin permissions just to run. If you need to restore only specific folders per user without granting wide compliance-role access, I've used EdbMails Office 365 migration tool for exactly this, lets you preview and pick folders before restoring, handles multiple PST files in one batch, and runs off a standard admin account. Worth testing on one mailbox first either way before doing this at scale.

May referring this, www.wintive.com/microsoft-365-best-practices/office-365-migration/pst-to-office-365-migration/