Last Updated 18th May 2026 Most large organizations are planning a project to remove every PST file from their ...
Last Updated 18th May 2026
Most large organizations are planning a project to remove every PST file from their environment, and for good reason. PST files have been in use for roughly three decades and have always carried the same risks: corruption, data loss, and theft. This blog sets out the ten PST migration best practices we apply on enterprise projects, covering how to find every file, choose a target platform and migration method, and decommission PSTs so the problem does not return. It applies whether you run a manual migration or use an enterprise PST migration solution.
A PST file is a Personal Storage Table, a Microsoft file format introduced in the mid-1990s with the Microsoft Exchange email client (later Microsoft Outlook) to let users store mail locally, outside their server mailbox quota. Users would create a PST on their desktop and drag emails into it to avoid the "mailbox approaching quota" warnings that small quotas produced.
The format changed several times over the years, mainly to add capacity: the original ANSI PST used by Outlook 97 through 2002 was capped at 2 GB, and the Unicode format introduced with Outlook 2003 raised that limit substantially. Almost from the start, PST files suffered intermittent corruption, especially when stored or accessed on removable media or network storage. End-users compounded the risk by keeping multiple "backup" copies of similar files in case the original failed.
A PST is not the same as an OST file. The OST is also a Microsoft Outlook format, but end-users never interact with it directly. It is the local cache Outlook creates for mail held in Exchange or Exchange Online.
PSTs were never intended for long-term storage, regardless of how end-users came to rely on them. Microsoft itself advises against using them this way. The recurring problems include a high likelihood of corruption on network locations, sprawling backup copies across devices and removable media, slow search and indexing on large files, the loss and theft risk of PSTs on portable media, broken access for remote and hybrid workers, incompatibility with the mobile versions of Outlook, and the difficulty they create for legal teams running eDiscovery. Those last two points matter most as work moves to the cloud: a PST that cannot be reached from a phone or searched by a legal team is a liability, not an archive.
A PST migration eliminates the PST files end-users have accumulated by ingesting some or all of their data into a target cloud platform — almost always Microsoft 365 - and then preventing new PST files from being created or old ones from being opened. We have never seen an organization simply switch PSTs off without first moving the data; the content inside them is too valuable to users to discard.
Blocking PST creation and access after the migration is the step that makes the project worth doing. Skip it, and within a few years, users will have rebuilt the same sprawl of files and reproduced the original problem. A PST migration is not a task to enter lightly. For a large, global estate, it requires significant planning, discovery, and governance work to complete successfully.
Every PST migration is different and brings its own challenges, but the following ten practices apply to almost every enterprise project. They hold whether you run the migration manually or use a dedicated product such as PSTComplete. We have been migrating PST files for large global enterprises for many years, and this is the sequence that consistently produces a clean result.
Start by finding every PST file, because they are almost always stored in two places: network shares and local hard drives. Each requires a different discovery approach.
On network shares, end-users tend to drop backup copies onto home drives and departmental or team shares. These are relatively simple to scan from a workstation with read permission across the relevant folders, usually with little or no impact on users. The scan returns a list of files, locations, sizes, and modified dates that gives the project team an initial picture of scope. Loading that data into Excel surfaces useful patterns — a single folder holding dozens of PSTs, or the same filename appearing in several locations — and it also exposes ownership problems early. A PST in the Sales share could belong to a current team member or a departed employee; in some organizations, the owning department can resolve that before the project starts.
Local hard drives are harder to scan. The target is files on local disks and removable media, ideally tied to a single user's Outlook profile so a migration product can assess ownership and locate the file accurately. Files attached to an Outlook profile are usually unique to that user, though the same user often keeps additional backup copies locally and on the network. Shared PCs add complexity, since multiple Windows and Outlook profiles on one machine all need to be assessed.
Build a written migration strategy before any data moves. It is where the planning lives: the migration decisions, the issue-resolution procedures, the proposed timetable, and, critically, whether end-users will be involved in the migration or whether discovered PSTs will be migrated without their participation. That single decision shapes communications, scheduling, and support load for the rest of the project.
Decide where the data will land before choosing how to move it. The usual targets are an on-premises Exchange mailbox, a Microsoft 365 mailbox, or a Microsoft 365 personal archive.
Migrating a large volume into a mailbox has a side effect worth planning for: Outlook caches mailbox data locally, so the first connection after a large import can trigger a significant download, and storage limits may be exceeded when the import is large. Many organizations migrate PST data into the Microsoft 365 personal archive instead, which avoids the local cache problem but depends on each user holding a license for that feature. In a Microsoft 365 hybrid configuration, the personal archive can be cloud-hosted even when the primary mailbox remains on an on-premises Exchange server.
There are two practical methods: a manual migration or a third-party product. The right choice is almost entirely a function of scale.
A manual migration has users drag their data into their mailbox or a personal archive, or has IT use the Microsoft Import service to push data into Azure storage or ship physical drives to Microsoft. Manual approaches give users flexibility over where data lands, but they carry real drawbacks. Users routinely drag enormous volumes into their mailbox and resurrect the quota problem the migration was meant to solve. The import-service route requires IT to build a PST mapping file, create an import job, optionally filter data, and run the import, a slow process that, with drive shipping, adds cost, handling, and the same removable-media risk you are trying to eliminate. Manual migration only works at small scale.
A third-party product is built for enterprise-scale migration, with automation, project governance, reporting, and auditing. For any project beyond a very small estate, this is the method we recommend.
A purpose-built migration tool earns its place on four fronts: governance, completeness, speed, and end-user impact.
On governance and reporting, a capable tool handles each individual PST while also giving the project team the controls to manage and report on a large-scale migration as a whole. On completeness, copying data is only part of the job, as we explain in copying data is just part of your migration project. A full migration also enables the personal archive, adjusts message size limits, removes PSTs from the Outlook profile once the copy completes, communicates with the user, and resizes mailboxes or archives as needed. On speed, a production-grade tool sustains high throughput once ramped, and should scale its migration environment up and down on demand, as PSTComplete does; familiarity with Service Protection Throttling is essential before any large migration into Microsoft 365. On end-user impact, the migration window for any user who still needs their PST data should be minimized, and some products, including PSTComplete, let end-users keep accessing their data during the migration itself.
Tell users what is happening before it happens, because PST data is often closely guarded. Much of it is old mail from a user's early days at the organization, sometimes from a previous employer, and telling them the data is "going" - which is how an unframed announcement is heard - is a difficult conversation.
Frame the migration as an upgrade to their PST files rather than a removal. Instead of manually maintaining backups and adding data, users gain an automated, always-accessible store and never again need to locate a particular USB drive from years ago.
Lock PSTs down during or immediately after the migration so the problem cannot recur. No organization wants to run a PST migration twice, and the protection is what prevents a repeat.
Most organizations apply Group Policy Objects (GPOs) to stop users from creating new PST files and from opening existing ones. These policies are applied to almost every machine, with a small number of IT admin workstations sometimes exempted in case a mailbox ever needs to be exported to PST.
Keep end-users informed throughout, not just at the start. We built end-user communication directly into the workflow orchestration engine in the ReMAD platform because it changes how smoothly a migration runs. Whether the workflows are standard or customized for a customer, users need to know four things: what will happen, when it will happen, what happens afterwards, and what to do if they hit a problem. With those built into the plan, users understand the process their data is going through and raise far fewer support tickets.
Establish who owns every discovered PST, because ownership is where most projects stall. Difficulty rises with location: users can identify their own files on their own machines, shared PCs are harder, network shares are harder still, and ownerless files are the hardest of all. An enterprise-ready migration product such as PSTComplete supports ownership resolution at every one of those stages.
Always validate the product in your own environment before committing. A vendor can describe how their product solves your challenges, but the only real test is running it against your users and your data. Cloudficient runs a proof of concept at no cost and with no commitment, in your environment, with settings configured to match it.
These ten practices cover the decisions that determine whether an enterprise PST migration succeeds or stalls. Every estate is different, but an organization that accounts for discovery, ownership, target platform, method, and end-user communication is on a clear path to a clean migration. If you want to see how this works on your own data, contact our migration team to arrange a proof of concept.
Timeline depends almost entirely on the number and size of PST files discovered, the target platform, and Microsoft 365 throttling limits. Discovery and ownership resolution typically take longer than the data copy itself. A third-party product that scales its environment on demand compresses the production migration window significantly compared with a manual approach.
Yes. Most organizations migrate PST data into a Microsoft 365 mailbox or, more commonly, a Microsoft 365 personal archive. The personal archive avoids large local Outlook caching but requires each user to hold a license for that feature. In a hybrid configuration, the archive can be cloud-hosted even when the mailbox stays on-premises.
The best tool for an enterprise estate is one that automates discovery and ownership resolution, scales throughput on demand, provides governance and audit reporting, and lets end-users keep access to their data during migration. Manual methods only work at very small scale. PSTComplete is built for enterprise-scale PST migration on these criteria.
PST files are almost always in two places: network shares and local hard drives or removable media. Network shares can be scanned from a workstation with read permissions, usually with no user impact. Local drives are harder and are best discovered through each user's Outlook profile. Expect duplicate backup copies of the same file across multiple locations.
You should block the creation of new PST files and the opening of old ones, typically through Group Policy Objects, rather than relying on deletion alone. Without this step, users rebuild the same sprawl within a few years and the original problem returns.
A PST is a local storage file end-users create and interact with directly to hold mail outside their server quota. An OST is the local cache Outlook creates automatically for a mailbox held in Exchange or Exchange Online; end-users do not manage it directly. Only PSTs are the subject of a migration project.
Looking for PST migration for large business? Will drive shipping suit your needs? Explore cloud-based alternatives for a seamless, efficient...
Data migration challenges make many transfers unsuccessful, but learning how to overcome them produces better outcomes. Cloudficient explains these...
Take a look at the top 9 things to consider when migrating PST data files .
-3.png?width=250&height=33&name=Untitled%20design%20(18)-3.png "Cloudficident Logo")
-3.png?width=527&height=69&name=Untitled%20design%20(18)-3.png "Untitled design (18)-3")
.png?width=200&height=26&name=Untitled%20design%20(18).png "Cloudficient"){kind=small}
.png?width=600&height=79&name=Untitled%20design%20(18).png "cloudficient logo")