Answer in brief: Pick a tool that gives you tenant‑to‑file visibility, accurate storage math, trend reporting, actionable insights (e.g., trim versions, archive inactive sites), and auditability—all mapped to Microsoft 365 realities, such as 1 TB + 10 GB/user pooled storage, version history limits, and Microsoft 365 Archive.
Shortlist vendors against the 9 features below, verify each against Microsoft’s own reports and limits, and favor products that turn insights into repeatable workflows.
Why this matters now
SharePoint storage is very costly once you exceed the base allocated quota on your tenant.
- Storage is pooled and finite. Tenants get 1 TB plus 10 GB per licensed user across SharePoint sites. Overruns can place environments at risk of read‑only behavior if not addressed.
- Versions and “cold” content eat quota. Each version can behave like a full copy; without limits, version sprawl quietly becomes your largest storage consumer. Microsoft’s version history limits feature helps, but you still need visibility to act.
Microsoft now surfaces a SharePoint storage report in the Microsoft 365 admin center (Usage → SharePoint → Storage), and site‑level usage analytics. Those are a baseline—but not enough if you need tenant‑wide diagnostics, cost projections, and clean‑up workflows at scale. That’s where a dedicated storage reporting tool pays off.
The 9 must‑have features (with practical tests)
Use this checklist to evaluate tools. For each item, you’ll see what to demand, how to test, and why it matters in Microsoft 365.
1. End‑to‑end visibility
(tenant → site → library → file → version)
What to demand: A single model that rolls up tenant totals and lets you drill to specific files and their version footprints—not just “current file size.”
How to test: Pick a site with a few very large PPTX files; confirm the tool reports total footprint including versions and flags “heavy version history.” Cross‑check with Graph’s driveItem versions API or site storage metrics.
Why it matters: Most bloat hides in versions and bins; native reports often show only current size or high‑level charts.
2. Accurate math for versions
What to demand: Correct calculation of storage consumed by file versions and clear visibility of where large and inactive files reside.
How to test: Delete sample content, confirm first → second stage behavior and quota effects; verify that version counts and sizes match spot checks.
Why it matters: Without accurate accounting, you’ll mis‑forecast spend and clean‑up ROI.
3. Trend reporting & forecasting
What to demand: Time‑series charts for usage growth by site and by content type, plus forecasting (“when do we hit 80%?”), aligned with Microsoft’s own Storage report expectations.
How to test: Compare a tool’s trendline for the last 6 months with Microsoft 365’s Usage → SharePoint → Storage tab (data lags 48–72 hours).
Why it matters: Capacity planning is a board‑level conversation once growth is visible.
4. Actionable insights (not just charts)
What to demand: Built‑in recommendations and guided actions: e.g., “Top libraries to trim,” “Sites inactive >180 days,” “Largest files not accessed in N months,” and easy-to-use playbooks to remediate.
How to test: Check whether the tool can identify and rank version‑heavy libraries and long‑tail cold files - then enable trimming/archiving steps linked to official guidance.
Why it matters: Leaders don’t need another dashboard - they need a to-do list that saves storage now.
5. Microsoft 365 Archive readiness
What to demand: Signals and filters for archive candidates (inactive sites/files), and awareness of Microsoft 365 Archive impacts - e.g., that archived sites leave active quota and move to a cold tier while staying discoverable via Purview/eDiscovery.
How to test: Choose a low‑activity site, flag it as an archive candidate, then verify post‑archive storage math once moved.
Why it matters: Archiving frees active storage and improves search/Copilot relevance by removing stale content from the “hot” surface.
6. Audit & compliance alignment
What to demand: Ability to correlate usage with activity (e.g., “rarely accessed but highly sensitive”).
How to test: Confirm with site owners that sites flagged as containing a specific content type actually match the description.
Why it matters: Storage reduction should respect governance rules; regulated orgs need defensible evidence chains.
7. Open, Microsoft‑native data foundations
What to demand: Use of Microsoft Graph for item metadata and versions.
How to test: Ask for the Graph endpoints used (e.g., drive/items/{id}/versions).
Why it matters: Avoid black boxes; you want to be sure that Microsoft architecture best practices are followed.
8. Robust scalability
What to demand: Support for large tenants and exportable CSV/Excel report results for cross‑team workflows—mirroring what Microsoft’s admin reports enable at baseline.
How to test: Ask for an index/crawl of your tenant, verify that all sites are detected, spot check that metadata like ownership is correctly reflected.
Why it matters: If it can’t scale safely, it won’t survive real operations.
9. “From insight to outcome” workflows
What to demand: Repeatable playbooks: trim versions in bulk, archive inactive sites, delete empty sites, assign ownership.
How to test: Execute a sample version‑trimming run (dry‑run + action), then confirm expected storage drop and audit trail. Compare against Microsoft guidance on version management and archiving.
✅ What “good” looks like in 2026 (mapped to Microsoft reality)
- Understands tenant math: Shows pooled storage, calculates average growth rates, forecasts projected costs.
- Treats versions as first‑class citizens: Surfaces top version‑heavy files/libraries and estimates savings from version history limits before you change anything.
- Respects lifecycle: Recommends archiving appropriate sites/files.
- Plays nicely with Microsoft reporting: Cross‑checks against Microsoft 365 admin site usage and tenant storage reports.
🚩Red flags to avoid
- “Current size only.” Ignores versions and bins—guaranteed undercount.
- No linkage to action. Pretty charts without trimming/archiving workflows invite shelfware.
- Opaque data model. If you can’t export or verify with Microsoft reports/APIs, you can’t trust it.
How SProbot fits (and when to use native tools first)
If you’re early in your journey, start with Microsoft’s OOTB SharePoint storage and site usage reports to baseline consumption and trends. They’re useful for quick checks and CSV exports.
When you need to go deeper—identify version bloat, rank clean‑up priorities, and execute—SProbot is designed for SharePoint storage cleanup, optimization, and reporting. You can see how it flags heavy version history, inactive files, and inactive sites, and then guides you through trimming versions or archiving.
🔗How to get a SharePoint Online health check
🔗How to use SProbot to free up storage
FAQs
Q1: Can’t I rely on Microsoft’s native reports alone?
They’re essential but high‑level. You’ll see tenant/site totals and some trends, but not granular version footprints, ranked clean‑up opportunities, or “click‑to‑trim/archive” playbooks. Most admins adopt a dedicated tool once growth accelerates.
Q2: Do versions really count as full copies?
Practically, yes—that’s why Microsoft introduced version history limits. Unbounded versioning can consume huge amounts of quota. A good tool quantifies this and helps you right‑size quickly.
Q3: What about archiving—will users still find content?
When you archive a site with Microsoft 365 Archive, it leaves active storage and moves to a cold tier. It’s no longer directly accessible to users, but Purview Content Search and eDiscovery can still find it; reactivation restores access. Plan communications accordingly.
