About the organisation
This organisation of 700 people in Ireland had grown into a fairly typical mid-sized manufacturing operation: multiple teams, multiple systems, and increasing reliance on Microsoft 365 for coordination between engineering, production, and procurement.
SharePoint had evolved naturally into the shared layer between these functions. It was easy to use, accessible from anywhere, and already embedded into Teams. But that ease of use came with a subtle side effect. Over time, it started absorbing types of data it was never really designed to hold.
By the time the IT team looked closely at storage, they were sitting at around 10TB, with growth that felt steady but unexplained.
The challenge
There was no single smoking gun. Instead, there was a growing suspicion that the platform was being used in ways that didn’t align with its strengths.
Engineering teams, in particular, were storing large design files directly in SharePoint, simply because that was the closest shared workspace available.
“We hadn’t made a deliberate decision to use SharePoint for engineering data. It just happened over time.”
That “just happened” behaviour is where most storage problems begin.
What SProbot surfaced
When the environment was analysed properly, two patterns emerged almost immediately.
The first was familiar: files that had been worked on for months or years had accumulated deep version histories. Taken together, these versions accounted for 1.3TB of storage, which translated into a meaningful recurring cost.
The second pattern was more structural: Entire categories of files were sitting in SharePoint that added very little collaborative value.
Content not intended for SharePoint
In this case, that mostly meant engineering artefacts.
CAD files, assemblies, simulation outputs - these are often very large, frequently regenerated, and not particularly suited to the kind of document-centric versioning SharePoint provides. They belong in systems designed to manage engineering lifecycles, not general-purpose collaboration tools.
The organisation already had this software in place, so relocating this material was not dramatic in percentage terms, but still removed 0.5TB, contributing roughly $1200 in annual savings.
More importantly, it stopped that category of data from growing further in the wrong place.
Inactive content, handled properly
A quieter but equally important issue sat in the background: project data that had simply aged out of active use.
Some of it still had value, particularly for reference or audit purposes. That portion was archived, reducing cost without losing access. A smaller subset - duplicates, temporary working files, outdated exports - could be removed entirely.
Between these actions, the organisation ended up with a layered approach to cleanup rather than a blunt one.
Results
Total annual savings: $4 819
With a SProbot cost of $2 820, this was not a dramatic short-term win - but it fundamentally changed how the organisation approached storage going forward.
