When an organization starts running low on SharePoint storage, the first instinct is usually straightforward: people must be uploading too much data.
That is part of the story, but it is often not the most useful part.
In a Microsoft 365 environment that has been active for years, storage tends to accumulate in layers. Current files grow. Old files remain in place. Version history builds behind frequently edited documents. Projects end, teams move on, and very little of that data ever leaves SharePoint.
The result is a storage problem that can be difficult to understand from the tenant-level number alone.
The storage number tells you how much, not why
The SharePoint admin center is good at showing total storage consumption. It can tell you that a tenant is using several terabytes and whether that number is approaching the available capacity.
What it does not immediately answer is the question that matters when you are trying to control cost: what is actually responsible for that usage?
Two tenants with the same total storage can have very different problems. One may be actively growing because of new project data. Another may have a large amount of historical content that has not been touched in years. A third may have a relatively modest set of current files with a surprisingly large amount of version history behind them.
Those situations should not be treated the same way.
1. Current files keep accumulating
This is the most obvious source of growth. New projects, photos, design files, spreadsheets, presentations, recordings, and other documents are continuously added to SharePoint.
In many organizations, that content has no natural retirement process. A project can be complete for years and still sit in the same document library as active work.
Nothing is technically wrong with that. SharePoint is doing exactly what it was asked to do. The challenge is that active collaboration storage and long-term retention are not always the same requirement.
Once enough old projects accumulate, organizations can end up paying premium SharePoint storage rates for content that is still important but rarely accessed.
2. Inactive content does not stop costing money
A file that has not been modified in three or five years may be effectively invisible to day-to-day users, but it still occupies the same storage as a file edited this morning.
This creates a useful distinction between important and active.
Old content can absolutely still be important. It may need to be retained for reference, compliance, historical records, or future reuse. But that does not necessarily mean it needs to remain in the most expensive storage tier forever.
The key is identifying which files are genuinely inactive without making assumptions based on a single folder, site, or department.
3. Version history can be much larger than expected
Version history is one of the least visible contributors to SharePoint storage.
Users generally think of a document as one file. SharePoint may be storing many historical versions behind it. That is useful when someone needs to recover an earlier edit, but across a large tenant those versions can add up quickly.
This is especially noticeable with large files that are edited frequently. A current document may only appear once in a library, while multiple historical copies contribute to storage behind the scenes.
That means a storage analysis that looks only at the size of the latest file can substantially understate how much space a library is really consuming.
4. Storage problems compound over time
The hardest part about SharePoint growth is that these factors compound.
New files are added while old files remain. Active files generate versions. Old versions remain behind documents that may themselves eventually become inactive. More sites are created, more projects finish, and the baseline keeps moving upward.
That is why storage can feel manageable for years and then suddenly become a recurring budget issue. The growth did not happen overnight; it simply crossed the point where the included capacity was no longer enough.
Start with visibility before deciding what to move
The solution should not begin with deleting files or setting an arbitrary archive rule.
It should begin with visibility.
Before making a storage decision, it helps to know:
- How much current-file storage exists across the tenant
- How much of that content has been inactive for one, two, three, or five years
- How much storage is tied up in historical versions
- Which sites and libraries are driving the largest opportunities
- How quickly overall storage is continuing to grow
Once those numbers are visible, the conversation becomes much more practical. Instead of asking, "How do we reduce SharePoint storage?" you can ask, "Which four terabytes are the best candidates to manage differently?"
That is why we built CBITS Lens
We built CBITS Lens because we wanted that analysis before making an archive recommendation.
Lens scans a Microsoft 365 environment and breaks storage into more useful categories, including file age and version-history estimates. The goal is not to automatically decide what should be archived. It is to show enough of the underlying storage picture to make that decision intelligently.
For some organizations, the right answer may be to leave everything exactly where it is. For others, a meaningful amount of older data can be moved to a lower-cost archive while remaining available when it is needed.
Either way, the first step is understanding where the storage is actually going.