SharePoint storage reclamation

The problem

The tenant was approaching its storage ceiling partway through the move off mapped network drives, so consumption was rising by design. The open question was how much more storage to buy, and answering it properly meant measuring first.

What I did

I wrote seventeen PowerShell scripts, numbered by stage and labelled by intent: read-only diagnostics, settings changes that delete nothing, and irreversible deletions. The read-only scripts were audited for the absence of any delete, set or update call, so "this one only reads" is a checked property, not a comment. Every destructive script runs as a dry run by default, and a supervisor process resumes the trimming after a usage limit, which is what made a job too big for one throttled session finish.

The audit found the shape of the problem, out of only 10 test sites: of 1,867,439 items, 7,633 files with more than ten versions (0.41%) held 1,279 GB of history, 96% of everything reclaimed. Item count predicted nothing; version depth on large files predicted everything. The largest library looked like version bloat and was not. 83% of its files had exactly one version, so I left it alone and spent the effort where the measurement pointed.

Keeping the ten most recent versions and never touching the current one removed 108,822 versions. With old recycle-bin items, 1.31 TB was reclaimed with eight errors in 7,633 files. All eight were the same locked files the dry run had flagged four days earlier.

A decision and its cost

The final report lists where its own numbers disagree. One batch of fifty audit rows was lost to a file lock while the deletions themselves succeeded, so the report says which count to cite for which purpose. Direct before-and-after measurement showed 88 GB more than the audit, because the platform freed some space on its own; the audit is therefore a lower bound, and it is the figure I quote.

I followed the cleanup with a written recommendation for the longer term: trimming history is a one-off gain bought with a recurring cost, and server-side version limits are the inverse. It also showed that the tenant's capacity follows a published licence formula, so planning for growth is arithmetic rather than a negotiation.