Short answer: our tenant was at 133% of its SharePoint storage limit. A read-only audit found that 36% of all storage was old file version history, and that two thirds of our document libraries had never received the tenant-wide automatic version trimming setting, because that setting only applies to libraries created after it is turned on. Setting limits on the existing libraries, trimming the accumulated history, and compressing inactive data exports and database backups cut total storage by about 55% in about 48 hours. No current file was deleted and no additional storage was purchased.
(Version history is the set of earlier copies SharePoint keeps each time a file changes. It counts against your storage quota exactly like a current file does.)
What was actually filling the storage?
About 36% of all storage was version history, not files. Earlier copies of files, most of which nobody would ever open again. More than all current Office documents and PDFs in the tenant combined.
The rest was just as lopsided:
| Category | Share of current files |
|---|---|
| Audio and video | 35% |
| Text and data exports | 29% |
| Compressed archives | 13% |
| Office and Power BI files | 12% |
| Database backups and installers | 9% |
| PDFs, images, mail, other | 3% |
Roughly 85% of the space was in content people rarely opened, and it was concentrated: about 10% of sites held about 75% of the storage. Everyday documents, the things people picture when they think of a document library, were a tenth of the files.
Why didn’t the tenant-wide setting prevent this?
Microsoft’s own documentation explains why, and it describes two separate gaps that most people collapse into one (as of October 2026):
| What you assume “enabled” means | What it actually does |
|---|---|
| Applies to all libraries | Applies to new sites and libraries only. Changes to organization-level version history limits do not update limits on libraries that already exist |
| Fixes the storage you already lost | Applies to new versions going forward. Setting or lowering a limit does not retroactively delete version history already consuming your quota |
Read those together. Turning the setting on protects libraries you have not created yet against versions that have not been written yet. Everything that existed before you flipped the switch is untouched, and changing it means setting the policy on each existing library yourself.
None of this is hidden. Microsoft documents it plainly. The gap is that none of it appears when you flip the switch. The admin center reports the setting as enabled, because it is, and does not indicate how much of the estate it will never reach.
A setting that reports itself as correct is a governance problem as much as a storage one. We cover that wider discipline in Strong Governance for Microsoft 365 Optimization.
Why does autosave make it worse?
Office autosave turns a modest file into a large one without anyone noticing. One file in our tenant was 308 megabytes. It had 45 previous versions and was consuming about 12 gigabytes on its own. Forty-five versions, against a default limit of 500. It was nowhere near the cap.
Nobody did anything wrong. Autosave writes a version; the library keeps 500 of them forever; and a file that several people touch each week quietly becomes one of the largest objects in the tenant. No one editing it can see any of this.
Large, frequently edited Excel and PowerPoint files are where this concentrates. If you check one thing after reading this, check there.
What came back, and how fast?
The tenant went from about a third over its storage limit to roughly 60% of it, start to finish in about 48 hours. No current file was deleted, and no additional storage was purchased.
| Step | Released | % of starting storage | % of limit after |
|---|---|---|---|
| Starting point | 133% | ||
| Set automatic version limits on every existing library | none | none | 133% |
| Trimmed version history older than one year, all 186 sites | 565 GB | 33% | 89% |
| Compressed CSV exports on one site | 57 GB | 3% | 85% |
| Compressed SQL Server backups | 98 GB | 6% | 77% |
| Compressed large .txt data exports | 20 GB | 1% | 75% |
| Compressed data exports across remaining sites | 189 GB | 11% | 61% |
| Emptied recycle bins | 2 GB | under 1% | 60% |
| Total | 931 GB | 55% | 60% |
The first row is the one that matters most and returns the least. Fixing the limits on the 65% of libraries that had never inherited them freed nothing that day. It is the only reason the other 55% does not quietly come back.
Version cleanup did most of the early work and did it fast. About 490 gigabytes, roughly 30% of total tenant storage, came back within the first six hours with zero failures. Compression finished the job over the following day. About 90% of the accumulated version history is now gone.
Before any of it ran near production, I tested the approach on a single site, file by file, before and after. That site dropped about 60% with every file intact. I would not have gone tenant-wide without it.
Compression returns vary enormously by file type:
- Inactive data exports compressed by more than a factor of 40.
- Uncompressed SQL Server backups compressed by roughly a factor of 15.
- Video, Office files and existing archives gained almost nothing, so I left them alone.
That last line matters more than the first two. The goal was to release as much storage as possible with almost no impact on anyone’s day. Old exports and database backups are rarely opened, so compressing them costs nobody anything. Compressing the Word files and presentations that people open every day would have been a daily irritation for the whole company, for almost nothing in return.
Microsoft is previewing a tenant-level job that sets every library’s policy and trims versions in one operation, gated behind a SharePoint Advanced Management or Copilot license (as of October 2026). Worth watching, but it only handles version history. That was about 60 percent of my reduction.
Every compressed file is still in its original folder and extracts in about a minute.
What can go wrong?
- Retention policies and legal holds. When a retention policy is in place, deleted content is retained, and you don’t get the space back. The audit will identify those sites and exclude them from the estimate so the figure you start with is one you can actually achieve.
- Expiration mode has a floor you probably didn’t expect. The Microsoft documentation makes it clear that manual expiration trim mode will not delete any versions created in the last 30 days and will always delete every version created prior to 1st January 2023, regardless of the age value you have set (as of October 2026).
- Jobs are slow on the larger sites. Microsoft notes that a trim job can take several days, depending on the site’s size.
Before you buy more storage
If your tenant is sending the same email, or a renewal or storage purchase is on the calendar, it is worth knowing your own numbers first. We turned this work into a read-only audit toolkit that estimates how much storage you can recover in any Microsoft 365 SharePoint environment without making any changes. If you want to see what yours would look like before you sign up for more capacity, talk to us about your Microsoft 365 costs.
Written by Ben Tight, VP of Operations and Delivery Lead at MetrixData 360.