Marcus is the IT coordinator at Halden Voss Architects, a 90-person practice running three studios. Every renewal cycle, the same email lands in his inbox from the finance director: the SharePoint storage add-on line item has gone up again, and nobody can say why.
Big files, small teams, no visibility
An architecture practice produces some of the largest individual files that ever land in a SharePoint library. Rendered visualisations run into the hundreds of megabytes each. Drawing sets exported as high-resolution PDFs for planning submissions can be a gigabyte apiece. Point-cloud scans from site surveys and reference CAD models add more again. None of this is unusual for the industry, but it means that a handful of closed projects, forgotten and untouched for years, can quietly hold more data than the entire active project list combined.
Halden Voss's document libraries were organised one site per project, which is sensible for permissions and client separation, but it meant nobody had ever looked at storage consumption across the full catalogue of sites at once. The finance director's question, "where is it all going," had no easy answer inside the native SharePoint admin center, which shows total consumption per site but nothing about what is actually inside each one.
Finding out where the space really was
Marcus ran a tenant-wide export through Report Master, which listed every file across every project site with its size, version count, and last-modified date in one Excel sheet. Sorted by size, the picture was immediate. A small number of projects, all completed and formally closed out between two and six years earlier, accounted for the majority of consumed storage. Within those projects, renders and high-resolution export PDFs made up most of the bulk; the working CAD source files were comparatively modest.
A cleanup that didn't touch active projects
With the closed-project sites identified, Marcus used two tools from ShareMaster's Space Master suite. First, the Version Trimmer ran across the identified closed-project libraries with a policy of keeping only the three most recent versions per file, since a completed project has no ongoing need for iteration history beyond a small final-state buffer. Second, for a small set of projects the firm's partners agreed were safe to fully retire, Bulk Delete Files cleared the largest render and export folders entirely, sending everything to the recycle bin rather than deleting it outright.
Nothing on the active project list was touched. The identification step through Report Master meant the cleanup could target exactly the sites responsible for the overage, rather than running a blunt, tenant-wide trim that risked disrupting current design work mid-project.
See what Space Master can clean up and keep reading for what changed at Halden Voss afterward.
What changed for next renewal
The combined trim and cleanup brought the tenant back under its allocated quota with enough headroom that the finance director's next storage question had a concrete answer attached to it. Marcus also set a new library-level version policy for any project site marked closed in the practice's project tracker, so the same render-history accumulation could not silently rebuild itself over the next renewal cycle. A short quarterly Report Master export now flags any site crossing a size threshold well before it becomes a renewal-time surprise.
For the mechanics of the version trim Marcus used, see the guide to trimming SharePoint version history, and for finding the worst offenders in your own tenant, the guide to finding large files in SharePoint Online covers the same Report Master approach in more detail.