Redfield Energy ran ShareMaster across 304 completed project sites over four weeks. Here is what they did and what they recovered.
| Metric | Before | After |
|---|---|---|
| Tenant storage used | 5.9 TB | 2.1 TB |
| Active external sharing links on completed sites | 4,200+ | 0 |
| Average version count per file (project sites) | 187 | 15 |
| Sites with permissions cleaned | 0 | 304 |
| Calendar time to complete | Four weeks (two staff, part-time) | |
The problem: seven years of project sites with no exit process
Meet James, IT administrator at Redfield Energy, a 500-person energy services company in Western Australia. Over seven years the organisation had provisioned a SharePoint Online project site for every engagement: scoping documents, contractor communications, regulatory submissions, and engineering drawings. When a project closed, nothing happened to its site. The data stayed, external sharing links remained active, and version histories kept accumulating unchecked.
By mid-2026, the tenant was consuming 5.9 TB. Microsoft 365 Extra File Storage add-on costs were running at AUD $600 per month, and the Microsoft 365 admin center showed storage climbing roughly 80 GB per quarter despite the project workload being flat. James had 304 sites tagged "Completed" in the site inventory, none of which had ever been formally decommissioned.
A PowerShell-based cleanup was scoped by an external consultant at three months of effort, largely because of the permissions and version history work involved. James needed a faster path.
The decommission approach: four phases, four weeks
Phase 1: Build a site inventory and measure storage
The first step was understanding exactly what was in each of the 304 sites. James exported the site list from the SharePoint admin centre's Active sites page, which gives each site's URL, owner, storage used and last activity. He then ran Report Master's Tenant Storage Metric, which walks every site in the tenant and reports to Excel, per library, the total size, file size and what trimming versions would save, and per file, the version size and file size.
The admin centre export confirmed that 217 of the 304 sites had shown no activity in over 18 months. The storage report showed version history was responsible for 71% of total storage: an average of 187 versions per file, built up across years of co-authoring and iterative document review. Engineering drawings in PDF format were the worst offenders. Some files carried 400+ full-copy versions, each consuming the full size of the drawing file.
The admin centre export became the project's tracking document. James added columns for decommission phase completed, confirming that each site had been processed before it was marked done. For a walkthrough of the inventory approach itself, see the site inventory guide.
Phase 2: Trim version history across all 304 sites
With the inventory complete, James configured the Space Master Version Trimmer to run across all 304 project sites. The policy: keep the 10 most recent versions per file, delete everything older than 12 months beyond those 10. For PDF and image libraries, he applied a tighter rule: keep 3 versions per file.
The trimmer ran overnight. By the following morning, version history across the 304 sites had dropped from 4.1 TB to 320 GB. The bulk of that reduction came from engineering drawing libraries where PDF version history had grown unchecked for years.
Phase 3: Revoke external sharing and clean up permissions
A ShareMaster Share Link Finder report, run on each site in turn, revealed 4,200+ active sharing links across the 304 sites, most shared with former contractors and project partners. Many of the underlying Microsoft Entra ID guest accounts were still active, even though the projects had closed years earlier.
Every one of these projects was closed, so no link on those sites needed to survive. James worked through the 304 sites one at a time, picking every library and running Share Link Finder's "Remove shared links", then "Remove all unique permissions" to restore inheritance on the files and folders (both remove modes need a Recycle Master or Clone Master licence). Each site took a few minutes, and the full permission cleanup fitted into the second week alongside his other work.
Phase 4: Empty folder cleanup and final storage pass
With versions trimmed and permissions revoked, the Space Master Empty Folder Remover ran across all 304 sites. It found more than 18,000 empty folders left behind by files that had been deleted or moved in earlier project phases. Removing them had a small direct storage impact, but materially reduced sync noise for any users still connected to those sites via the OneDrive for Business sync client.
A final storage report from Report Master showed total tenant usage at 2.1 TB. The $600/month Extra File Storage add-on was no longer needed. James cancelled it the same day.
Try ShareMaster free for 14 days
What actually drove the 3.8 TB reduction
Three sources accounted for the recovered storage:
- Version history trim: 3.78 TB recovered. This was by far the largest lever. Seven years of uncapped versioning, combined with PDF and image libraries where every version is a full copy, had created a storage mass that dwarfed the working content beneath it. The 500-version-per-file default limit sounds generous until you apply it to 60,000 files across 304 sites.
- Empty folder removal: negligible storage, material hygiene benefit. Eighteen thousand empty folders do not consume meaningful quota, but they generate sync client errors and add noise to navigation. Removing them was a low-effort quality-of-life improvement.
- Recycle bin clearing: 180 GB recovered. ShareMaster's Recycle Master cleared the tenant-wide recycle bin at the end of the project, recovering an additional 180 GB that had been sitting in the second-stage bin from files deleted during earlier internal cleanup rounds.
Four lessons for SharePoint admins
The Redfield project surfaced four patterns that appear in almost every organisation with a long-lived Microsoft 365 tenant:
- Version history is almost always the largest avoidable storage cost. Most admins audit current files but never run the version numbers. The ratio of version history to working content is frequently 10:1 or worse in active project libraries. Start with a version audit before anything else.
- Sharing links outlive the context that created them. A contractor who finished a project three years ago may still hold an active sharing link to a confidential folder. Auditing and revoking stale external sharing should be a standing governance task, not a one-off cleanup.
- A site inventory is the prerequisite for structured decommission work. Without a structured view of what each site contains, who owns it, and how much it costs, decommission work is guesswork. The admin centre site export, with Report Master's storage figures alongside, gave James a dataset to prioritise against and track progress through.
- Trim version history before any archive, migration, or export. If Redfield had archived the sites before trimming, they would have transferred 4.1 TB of version data to the archive destination unnecessarily. Trim first, then move or archive.
Applying this to your environment
If your organisation has more than 50 SharePoint Online sites that have been active for over two years with no formal version policy, the probability that version history is your largest controllable storage cost is high. The practical starting point is a Report Master storage export to see the numbers clearly.
The same four-phase approach scales to smaller environments without modification. A 20-site cleanup runs exactly like a 300-site cleanup - the tooling is identical, only the volume differs.