Migrate PST to Office 365: Network Upload and Drive Shipping

PST files pile up. A laptop refresh, a departing employee, a forensic export from legal, a decade of personal archives that someone finally wants in the cloud. Microsoft's first-party way to land them in Exchange Online is the PST import service in the Microsoft Purview compliance portal. It has two flavours: network upload to Azure Storage, and drive shipping for hardware-scale datasets. Most migrations use network upload because it is free, scriptable, and Microsoft has tightened it considerably over the last few years.

When to use network upload versus drive shipping#

Both methods end with PSTs sitting in an Azure Storage container that a Microsoft-side worker process reads and writes into target Exchange Online mailboxes. The only difference is how the PSTs reach Azure.

• Network upload — You push PSTs through AzCopy or Storage Explorer over a SAS URL. No charge from Microsoft. Limited by your internet uplink.
• Drive shipping — You copy PSTs onto an encrypted external drive and physically ship it to a Microsoft facility. Microsoft charges a per-GB fee. Only worth it for terabyte-plus migrations or sites with no usable uplink.

For anything under 1 TB or any site with a stable 100 Mbps or better uplink, network upload wins. The decision tree is rarely close.

Prerequisites#

The import service has more moving parts than most M365 admin tasks because it touches both Exchange Online and Azure Storage.

Locate the PSTs#

Centralise the PSTs on a workstation with enough free disk to hold all of them at once. Network shares are fine to source from but copy to local SSD before uploading. AzCopy reading from a SMB share over a slow link causes timeouts and partial uploads.

Typical PST locations:

• C:\Users\<user>\Documents\Outlook Files\
• C:\Users\<user>\AppData\Local\Microsoft\Outlook\
• Custom paths set by group policy or by users who moved their archive
• Departed employee laptops being decommissioned

Verify each PST#

Run scanpst.exe against every file:

"C:\Program Files\Microsoft Office\root\Office16\scanpst.exe"

A PST that scanpst flags will likely fail the import or import partially with no clear error. Repair until scanpst returns clean. Keep the .bak files in case repair removes something important.

Convert any oversized PSTs#

The PST import service handles files up to about 20 GB reliably. Larger files often fail with vague errors about Azure blob timeouts. Split files over 15 GB using Outlook's archive feature (move folders into separate PSTs by date) or a dedicated PST splitter.

Confirm target mailbox readiness#

Each target mailbox needs:

• Enough storage headroom for the incoming PST.
• Litigation hold or retention policies that won't block the import.
• A primary SMTP address that matches the mapping CSV exactly.

For PSTs bigger than the mailbox quota, enable the In-Place Archive and use the IsArchive flag in the mapping to land the content in the archive instead of the primary mailbox.

Run the network upload#

1. Stage the PSTs

   Copy every PST into one working folder on the migration workstation. Use a consistent naming convention that maps to the target mailbox, for example jdoe-archive.pst for jdoe@contoso.com. The mapping CSV later references these filenames exactly, so a typo here costs you a re-run.

2. Get the SAS URL from Purview

   Sign in to the Microsoft Purview compliance portal as your account with the Mailbox Import Export role. Navigate to Data lifecycle management, Microsoft 365, Import. Create a new import job, name it something descriptive like pst-import-may-2026, and select Upload your data. The wizard provides a SAS URL valid for around 30 days and a link to download the latest AzCopy executable.

   Copy the SAS URL to a secure note. The URL is a credential. Anyone who has it can write to your Azure container.

3. Upload with AzCopy

   Open an elevated command prompt on the workstation where the PSTs are staged. Run AzCopy:

   azcopy copy "C:\PSTStaging\*.pst" "<SAS-URL>" --recursive
   

   AzCopy displays per-file progress. At 100 Mbps sustained uplink you can expect roughly 35 to 40 GB per hour. The session can be paused and resumed; AzCopy checkpoints automatically. If a single file fails midway, AzCopy retries it.

   Use Azure Storage Explorer with the same SAS URL afterwards to confirm every PST is present and matches expected size. Missing files or zero-byte uploads are common when AzCopy crashes silently on flaky links.

4. Build the mapping CSV

   The mapping file is a CSV with these columns:

   Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,ContentCodePage,SPFileContainer,SPManifestContainer,SPSiteUrl
   

   For PST imports, only Workload, FilePath, Name, Mailbox, IsArchive, and TargetRootFolder matter. Example row:

   Exchange,,jdoe-archive.pst,jdoe@contoso.com,FALSE,/Imported,,,,
   

   FilePath is blank when PSTs are at the container root, which is the normal case. TargetRootFolder controls where the PST lands in the destination mailbox. /Imported is a sensible default; messages land under an Imported folder rather than mixing with live content.

5. Submit and analyse

   In the import job wizard, upload the mapping CSV. Microsoft runs an analysis step that checks each row against the Azure container and the target mailbox. Errors at this stage are usually:

   • PST filename in the CSV does not match the file in Azure (case-sensitive).
   • Target mailbox SMTP address does not exist or is misspelled.
   • Mailbox is on litigation hold without the right Mailbox Import Export role.

   Fix the issues, re-upload the mapping, re-analyse until clean.

6. Filter or import everything

   Microsoft offers an optional filtering step where you can exclude messages by age or by folder. For most migrations, import everything. If the source PST has 15 years of content but legal only requires 7, set the date filter here rather than pre-trimming the PST.

7. Run the import

   Submit the job. The import runs server-side in Azure. Progress is visible in the compliance portal under the import job. A typical 10 GB PST takes 2 to 6 hours from job submission to completion. Larger jobs take proportionally longer; the service parallelises across PSTs so 10 files of 5 GB each finishes faster than one 50 GB file.

After the import#

Reconciliation matters here as much as anywhere.

Verify per-mailbox counts#

Open each target mailbox in OWA or Outlook. Confirm the Imported folder (or whatever you set as TargetRootFolder) contains the expected folder hierarchy. Cross-check folder counts against the original PST opened in Outlook on a workstation.

Check archive landings#

If you used IsArchive,TRUE, the content lands in the user's online archive, not the primary mailbox. Users need to enable the archive in Outlook (View, Folder List) to see it. If they were not expecting archive landings, you will get tickets.

Confirm retention policy compatibility#

Imported messages inherit the user's existing retention policy from the moment they land. A message dated 2015 imported today is subject to whatever retention rules apply now. If the policy auto-deletes anything older than 5 years, the imported content evaporates within hours of completion. Verify policy compatibility before submitting.

Common failure modes#

Mailbox Import Export role missing#

The compliance portal greys out the Import option. Assign the role in Exchange admin centre, then sign out completely (close all browser tabs) and back in. Role propagation takes about 15 minutes.

SAS URL expired#

The 30-day clock started when you generated the URL, not when you started uploading. For long-running multi-week migrations, generate a fresh SAS for each batch.

Cannot find PST in storage#

The mapping CSV filename does not match the Azure blob name. Case matters. JDoe.pst and jdoe.pst are different files.

Message too large for destination#

A single message in the PST exceeds Exchange Online's 150 MB message size limit. Rare but happens with old PSTs containing huge attachments. The import log lists the affected messages; extract them manually and deliver separately.

Folder name contains invalid characters#

Exchange Online rejects folder names with certain characters that were legal in older Outlook versions. Rename the folder in the source PST opened in Outlook, then re-export.

When to use a third-party tool instead#

The first-party network upload is fine for one-off projects, batched well, with technical people running it. It struggles when:

• PSTs are scattered across user workstations and you cannot centralise them easily.
• You need per-folder mapping (a specific PST folder to a specific mailbox folder).
• You're doing rolling migrations where new PSTs appear weekly.
• You want detailed per-message logs rather than the summary the import service produces.

Desktop migration tools that read PST and append over IMAP or EWS bypass the Azure staging entirely. They are slower per gigabyte than network upload at scale but easier to operate for distributed sources. The PST to Outlook desktop walkthrough covers the simplest version of that flow.

For format background, see the PST file glossary entry and the broader PST, MBOX, and EML migration guide. If your source is Gmail rather than PST, the Office 365 migration guide covers cutover and staged options. If you are heading to Google instead, the PST to Gmail walkthrough covers the IMAP-append route.