SharePoint Site Decommission at Scale

Redfield Energy ran ShareMaster across 304 completed project sites over four weeks. Here is what they did and what they recovered.

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: Generate a site inventory with Report Master

The first step was understanding exactly what was in each of the 304 sites. James connected ShareMaster to the tenant via Report Master and generated an Excel export covering site URL, last modified date, total size (current content plus version history), site owner, and file count. The export ran across all 304 sites in under 25 minutes.

The output confirmed that 217 of the 304 sites had not been accessed in over 18 months. 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.

This report 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 scan using ShareMaster's Shared Links and Permissions tool revealed 4,200+ active sharing links across the 304 sites, most pointing to 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.

ShareMaster's Shared Links and Permissions tool let James filter all sharing links to those on the 304 project site URLs, then bulk-revoke in a single operation. James then identified and removed unique permissions at library and folder level, restoring inheritance from the site level. The full permission cleanup took one afternoon.

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:

1. 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.
2. 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.
3. 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 Report Master inventory export gave James a dataset to prioritise against and track progress through.
4. 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.

Learn more about Space Master