The obvious way to migrate a local PST into a cloud mailbox is: copy the file somewhere safe, then read from that copy. It's obvious because it's careful — you don't want a migration tool touching someone's live Outlook data file directly. We built it that way too, at first.
Where it breaks down is scale. We were migrating PCs with PST files up to 120 GB. Our pipeline had two copy steps: an export step that copied the original into a backup folder, and an import step that copied that backup into a scratch file before reading it — so the code doing the actual parsing never had to worry about the backup being modified underneath it. Reasonable in isolation. Added up, a 120 GB mailbox needed the original 120 GB (untouched, on whatever drive it started on) plus a 120 GB backup plus a 120 GB scratch copy, at the same time, on the same machine — and the backup and scratch copy both landed on the OS drive by default, not wherever the original happened to live.
A lot of office laptops have a few hundred gigabytes of free space, most of it already spoken for by Windows and installed software. Asking for 240 GB of headroom on the C: drive for one mailbox isn't a corner case at that point — it's a guaranteed failure on your largest, most important accounts.
The fix wasn't clever, just disciplined: figure out what each copy was actually protecting against, and drop the ones that weren't protecting against anything real. The scratch copy existed so a concurrent re-export couldn't corrupt a read in progress — but that's a narrow, specific race, not a reason to duplicate every byte on disk. We read the backup directly instead, with a short bounded retry for the one moment that race can actually occur (a re-export writing to the same path), and had the export side back off cleanly if it detects an import already using the file. One less full copy of every mailbox, and the biggest accounts stopped being the ones most likely to fail.
If you're scoping a similar migration: don't just budget for the mailbox size. Ask exactly how many full copies of the data your pipeline makes before anything reaches the destination, and where each one lands on disk. That number is usually smaller than whoever built the pipeline assumed — including us, the first time.