Trim SharePoint Version History: Automatic Limits That Reclaimed 30–40% Storage

Our SharePoint storage bill was climbing and the culprit was not files — it was versions of files. Two changes fixed it: switching the tenant to Automatic version history limits, and running one PowerShell command against each existing site. Between them we reclaimed roughly 30–40% of our total storage. Here is exactly what we did, and the retention schedule you are signing up for.

Step 1: turn on Automatic limits for everything new

SharePoint's Automatic mode tiers retention by age instead of keeping every single edit. Turning it on at the organization level applies it to all new sites and libraries from that point forward — no per-library configuration to remember.

Once it is on, this is what users can restore as versions age:

• First 30 days — every version, up to the 500-version count limit.
• 30 to 60 days — hourly versions (the version created at the top of the hour).
• 60 to 180 days — daily versions (the version created at the beginning of each day).
• Beyond 180 days — weekly versions (the version created at the beginning of the week), kept indefinitely until the 500 count limit is reached.

The service trims the intermediate versions automatically as each milestone is reached — you never run a cleanup for new content again. After six months, a busy document settles down to one restorable version per week instead of hundreds of near-identical copies. Microsoft's full breakdown is in Understand version storage under automatic limits.

Step 2: apply it to existing sites with PowerShell

The organization setting only reaches new sites and libraries. Your existing sites — the ones holding years of accumulated versions — keep their old behavior until you trim them. That takes one command per site in the SharePoint Online Management Shell:

New-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl -Automatic

This queues a background batch job that trims the site's existing version history down to the Automatic schedule — same tiering as above, applied retroactively. Loop it over your site list and the whole tenant is covered. The full script and parameter options are in Microsoft's guide to trimming existing versions using PowerShell.

What actually happens to the bytes

Two timing details matter before you declare victory. The batch jobs run in the background, so large sites take a while to process. And trimmed versions go through the recycle bins, which hold deleted content for up to 93 days — the reclaimed space shows up in your tenant storage figures over the following weeks, not the same afternoon. We watched ours fall steadily and land at roughly 30–40% below where it started.

To prove the saving, measure before and after with the same tool. A Smart Storage Analyzer report with "Include version history size" ticked gives you a per-file before number, and the version history storage calculator estimates what a trim is worth before you touch a setting. If you want the full picture of every version history setting and where it lives, see version history settings explained and the version history complete reference.

Is the Automatic schedule enough for real work?

For a general collaboration tenant, yes — comfortably. Everything from the last month survives intact, which covers the "I just broke this document" restores that make up almost every real-world request. Past that, an hourly, daily, then weekly snapshot is a generous safety net: you can still answer "what did this look like last quarter?" without paying to store every autosave since 2021. Libraries under strict records requirements can keep Manual limits per library while the rest of the tenant runs Automatic.