SharePoint Storage Optimization
An assessment and implementation service that finds what is actually consuming your SharePoint Online storage and reclaims it. We export metadata for every file and every version across the sites in scope, rank the real storage drivers — version history, large inactive files, media and archives, Power BI working files, duplicates, and non-business file types — and turn them into approval-ready recommendations with a measured saving against each one. File contents are never opened, nothing changes until you approve it, and we then implement the approved scope and measure the result.
What this engagement is
The Microsoft 365 admin center tells you how much SharePoint storage you use and that it keeps growing. It does not tell you why, and it does not tell you what to do about it. Buying extra storage is the easy answer, and it is the one most tenants end up paying for year after year. This service answers the why. We collect metadata for every file and every version in the sites you nominate, then analyze that data file by file rather than site by site. That is what surfaces the real drivers — in most tenants the largest single one is accumulated version history, which is invisible in any standard report because it hides inside files that look small. It also surfaces content that should not be in SharePoint at all: installers, disk images, personal media, and games. You get a ranked picture of where the storage went, a costed recommendation against each driver, and file-level lists your approvers can actually work from. Where you want it, we then implement the approved actions and measure the reduction. In a recent engagement on a 1.8 TB tenant, this took the footprint down to 1.1 TB — a 38% reduction — with every action signed off before it was carried out. That tenant held four SharePoint sites and more than 145,000 files, each analyzed individually; roughly 500 GB of the 1.8 TB was current file content, and about 1.3 TB was version overhead. The service runs from three days, depending on how many files are in scope and how heavily they are versioned.
Success criteria
What you receive
How the work unfolds
Agree which sites are in scope and grant the read-only access the export needs. No write permissions are requested at this stage.
Collect metadata for every file and all of its versions across the sites in scope: site, library, folder path, file type, size, created and modified dates, last editor, version count, and total size with versions. File contents are never opened.
Analyze the exported data to identify and size the actual storage drivers, and produce the tenant and per-site breakdown.
Turn each driver into a recommendation with a decision question, rationale, estimated saving, risk note, and the supporting file list.
Walk the recommendations through with whoever you have put in charge of the decision. Tenant-wide items, such as version retention policy, are normally approved by a Global Administrator or the tenant owner; content-level items can be delegated to site or data owners where you want their judgement. Each item is approved, rejected, or deferred, and the decisions are documented.
Execute the approved scope only: one-time version cleanup, archive and cold storage moves, version limits and retention policies, and agreed deletions.
Measure the footprint after the work and confirm the actual reduction against the estimates.
Prerequisites
Who does what
IT Partner
- Export file and version metadata from the sites in scope
- Analyze the data and identify the storage drivers with their measured impact
- Produce the recommendations, the supporting file lists, and the remediation plan
- Present the findings and support the review and approval process
- Implement the approved actions and validate the resulting storage reduction
- Recommend and, where approved, configure version retention policies
Your team
- Approve the read-only access needed for the export
- Confirm which sites are in scope
- Nominate who approves what: a Global Administrator or tenant owner for tenant-wide decisions, and site or data owners for their own content if you choose to involve them
- Review the recommendations and approve, reject, or defer each item
- Confirm any retention, legal hold, or compliance constraints that affect the proposed actions
- Provide the target location for archived content, if archive moves are in scope
What's not included
Limitations & technical notes
Frequently asked questions
Do you read the contents of our files?
No. The analysis works on metadata only — file name, type, folder path, size, dates, last editor, and version count. We never open, download, or store the contents of a document. This is also why the export needs read-only access and nothing more.
Will anything be deleted or moved without our approval?
No. The assessment changes nothing at all. In the implementation phase we execute only the specific items your approvers have signed off in writing. Rejected and deferred items are documented and left alone.
Why is version history usually the biggest problem?
SharePoint keeps a copy of a document every time it is saved, and by default it keeps a great many of them. A 100 MB workbook edited daily for two years can be carrying tens of gigabytes of history behind it. Nothing in the admin center shows this, because the file itself still looks like 100 MB.
How long does the analysis take?
From three days. It depends on how many files you have and how heavily they are versioned, not on how many gigabytes they occupy, because version data has to be requested for each file individually. A tenant with 100,000 files takes a few hours to export; a tenant with over a million takes considerably longer. We confirm the estimate for your scope before starting.
Can we run this on just one site first?
Yes. Scoping to your largest site is a common way to start — it produces results faster and usually accounts for most of the potential saving, since storage is rarely spread evenly across sites.
Why do the savings not add up to the total?
Because the categories overlap. A large ZIP archive that has not been touched in two years appears under inactive files and under media and archives at once, and reclaiming it once does not reclaim it twice. The report gives both the per-recommendation figures and a realistic combined total.
Who approves the recommendations?
Whoever you decide. In most engagements a Global Administrator or the tenant owner signs off the whole scope, which is the simplest route and the one we default to. Where content is sensitive or ownership is clearly divided, tenant-wide items such as version retention policy stay with the Global Administrator while content-level decisions are delegated to individual site or data owners. Both models work; we agree yours before the review stage so nothing stalls waiting on the wrong person.
What happens to files under legal hold or a retention policy?
They are reported so you can see the storage they occupy, but they are never actioned without documented sign-off from whoever owns compliance in your organization. Anything in the Preservation Hold Library is treated the same way.
What do you mean by non-business file types?
Content that ended up in SharePoint but has no business reason to be there — software installers and ISO images, personal photo and video libraries, game files, and similar. Individually they look harmless; across a tenant they add up, and they carry governance risk as well as storage cost. We report them together with the file owner and location, so the decision is yours, rather than deleting anything on our own judgement.
Will the problem come back?
A one-time cleanup on its own does come back, which is why version retention policy is part of the recommendation set rather than an optional extra. The cleanup removes the accumulated overhead; the policy stops it rebuilding. We also set up repeatable reporting so growth stays visible.
What kind of reduction is realistic?
It depends entirely on how your tenant has been used. On a recent 1.8 TB engagement, approved actions reclaimed roughly 685 GB — a 38% reduction. The largest contributors there were a one-time version history cleanup (roughly 360 GB) and archive moves for inactive files (roughly 340 GB), followed by Power BI working-file cleanup (about 140 GB) and non-business file removal (about 18 GB). Tenants with disciplined version settings and little archived content will see less. The assessment tells you your own number before you commit to any cleanup.
Do you support the storage decisions after the engagement?
The engagement itself ends with the validation report, and the version retention policies we configure keep working after we leave. If you want ongoing SharePoint help beyond that, our SharePoint Engineer as a Service covers it as a separate service.