SharePoint Online Storage: Usage, Main Consumers, and Optimization Strategies

Most organizations treat SharePoint Online as infinitely scalable, until a warning appears in the SharePoint Admin Center. That’s exactly what happened with a tenant I manage. With over 8,000 Microsoft 365-licensed users, the tenant had a total available storage of approximately 81 TB. Everything felt comfortable, until it wasn’t.

A few weeks ago, the Storage Usage Alert appeared in the SharePoint Admin Center. This alert fires at 80% usage, which for the tenant meant roughly 65 TB. I pulled the trend data and found the tenant was growing at ~1.7 TB per month. That left about 9 months of runway.

Here’s a quick snapshot of the numbers:

How Is Available Storage Calculated?

SharePoint Online uses a pooled storage model across the entire tenant. The formula is straightforward:

Total Storage = 1 TB (base) + 10 GB × number of eligible licensed users

Not all license types contribute to this pool. Eligible licenses include Microsoft 365 Business Basic/Standard/Premium, Office 365 E1/E3/E5, Microsoft 365 E3/E5, and SharePoint Online Plan 1 & 2. The maximum storage per individual site collection is 25 TB, regardless of tenant pool size.

What’s Eating Our Storage?

In this tenant most of the content lives in SharePoint sites connected to Microsoft Teams, both standard team channels and private channels. Non-Teams SharePoint sites contributed very little by comparison.

To identify the biggest contributors all sites were categorized into three buckets:

The RED category alone — just 60 sites and channels — accounted for 40% of all tenant storage. Every single one of them had recent modification dates, meaning they were active and still growing.

Built-in Optimization: Version History Limits

One of the most impactful and often overlooked levers is version history. By default, SharePoint creates up to 500 major versions of every file, with no expiration. For an active document touched 10 times a day, that adds up quickly.

Microsoft offers three modes for version limits, configurable at tenant, site, or library level:

• Automatic (recommended by Microsoft): An algorithm keeps more recent versions and progressively fewer older ones. Active files retain many versions; inactive files are pruned over time. This is Microsoft’s recommended setting for balancing recovery capability and storage efficiency.
• Manual – count only: You define a fixed maximum (e.g., 100 major versions). The oldest is deleted when the limit is exceeded. Files never expire regardless of age.
• Manual – count + expiration: You define both a maximum count and an expiration period (e.g., delete versions older than 180 days). This is the most aggressive option but risks losing rollback capability for old files.

⚠️ Critical caveat: Changing the version limit setting at the tenant level via the Admin Center does not retroactively update existing sites or document libraries. You must use PowerShell to loop through all sites and apply the new settings. Use Set-SPOSite with -EnableAutoExpirationVersionTrim, -MajorVersionLimit, and -ExpireVersionsAfterDays, or the PnP equivalent Set-PnPSiteVersionPolicy.

# Example: Set manual version limit on a site, apply to existing libraries
Set-SPOSite -Identity "https://puntobello.sharepoint.com/sites/mysite" `
  -EnableAutoExpirationVersionTrim $false `
  -MajorVersionLimit 100 `
  -ExpireVersionsAfterDays 180 `
  -ApplyToExistingDocumentLibraries

Triggering Cleanup: Batch Trim Jobs

Configuring version limits is only the first step. After updating tenant or site settings, you’ll typically want to actively clean up existing versions instead of waiting for background timer jobs to process them over time.

Microsoft provides version trimming jobs for this purpose.

First: Generate a Version Usage Report (Impact Analysis)

Before deleting anything, you should estimate the impact.

Microsoft provides a built-in report that simulates trimming and shows:

• How many versions will be removed
• How much storage will be reclaimed
• Which libraries are most affected

# Generate a version trim impact report for a site
New-SPOSiteFileVersionExpirationReportJob -Identity "https://puntobello.sharepoint.com/sites/mysite" `
    -ReportUrl "https://puntobello.sharepoint.com/sites/mysite/reports/MyReports/VersionReport.csv"

When using automatic expiration, the expiration date for each version is available in the “AutomaticPolicyExpirationDate” column. Any version with an expiration date earlier than the current date will be deleted once a trim job is queued with the Automatic parameter.

Then: Queue the Actual Trim Job

Once validated, you can queue the actual cleanup job.

# Queue the actual version trim job using automatic policy
New-SPOSiteFileVersionBatchDeleteJob -Identity "https://puntobello.sharepoint.com/sites/mysite" `
    -Automatic

This job:

• Runs asynchronously in Microsoft 365
• Processes large libraries in the background
• Deletes versions exceeding your configured policy (based on the parameters)
• Cannot be undone

You can monitor job status using:

# Get progress of the version trim job
Get-SPOSiteFileVersionBatchDeleteJobProgress -Identity "https://puntobello.sharepoint.com/sites/mysite"

Storage Quota Management

By default, every SharePoint site collection can grow up to 25 TB — the per-site maximum. Leaving this uncapped for all sites means there’s no visibility, no governance, and no early warning per site.

A practical tiered quota model:

Setting quotas via PowerShell is straightforward with Set-SPOSite -StorageQuota (value in MB) and -StorageQuotaWarningLevel. Maintain a SharePoint list or automated report to track which sites have non-standard quotas and why. This creates accountability and makes future reviews much easier.

Sensitising Users

SharePoint and Teams give users the feeling of unlimited, costless storage — and that perception drives behavior. A few approaches to change this:

• Communicate real costs: Calculate a per-GB cost that includes the proportional share of included storage plus any overage pricing (e.g., 0.30 CHF/GB). Share this with team owners.
• Make it visible: Deploy an SPFx widget in Teams or SharePoint that displays the site’s storage usage and estimated cost, right where users work.
• Frame it correctly: Behind every Teams site is infrastructure managed by a real team with real costs. Making that visible changes how people treat the space.

SharePoint Advanced Management

If you need more automated governance controls, SharePoint Advanced Management (SAM) extends the admin toolkit significantly. It requires a Copilot license or the standalone Advanced Management add-on.

Key features relevant to storage governance:

• Inactive site policies: Detect sites with no visits, edits, or file activity and automatically notify site owners. Admins can set the policy to do nothing, make sites read-only, or archive them.
• Site ownership policies: Ensure every site always has a responsible owner to respond to lifecycle decisions.
• Recurring site attestations: Site owners periodically confirm whether their site is still needed — sites that go unconfirmed can be flagged or archived.

Note: In our environment, MS Teams lifecycle is governed by a third-party tool, and non-Teams SPO sites are managed via CI/CD pipelines. Features of advanced management would therefore have limited incremental value for us, but for organizations without existing governance tooling, it’s a strong option.

Storage Optimization Impact Analysis

To understand the real-world impact of version history optimization, we analyzed a document library with the following baseline metrics:

• Number of documents: 3,567
• Total number of versions: 35,242
• Total storage consumed by all versions: 267.3 GB
• Storage marked for automatic policy expiration: 153.22 GB

What Do These Numbers Tell Us?

Version Density

On average:

• ~9.9 versions per document (35,242 ÷ 3,567)

This indicates a moderately active library, where version accumulation contributes significantly to storage growth.

Potential Storage Reclaim

Out of 267.3 GB total version storage:

• 153.22 GB is already marked for expiration under the automatic policy.

That means:

• ~57.3% of total version storage can potentially be reclaimed
• Only ~114.08 GB (42.7%) would remain after trimming

This is a substantial optimization opportunity.

Storage Optimization Summary

If the trim job is executed:

• We reduce version storage by over half
• The library footprint shrinks from 267.3 GB to approximately 114 GB
• That is a net reclaim of ~153 GB

In practical terms:

• Lower SharePoint storage consumption
• Reduced backup footprint
• Faster migrations and tenant-to-tenant moves
• Improved long-term storage governance

What’s Next: Moving from Analysis to Action

With the impact analysis complete, it’s time to move from planning to execution.

🚀 Phase 1: Enable Automatic Version History

In our tenant we are now switching version history settings to Automatic across the targeted sites. This allows SharePoint to intelligently manage version retention based on file activity and age, balancing recoverability and storage efficiency.

📊 Phase 2: Generate Reports and Analyze Impact

Before deleting any versions, we will:

• Generate report-only trim jobs
• Review projected storage savings
• Identify high-impact libraries
• Validate assumptions with stakeholders

This ensures transparency and prevents unexpected data loss.

🧹 Phase 3: Queue Cleanup Jobs

After validating the reports, we will begin queuing trim jobs to enforce the automatic policy.

These jobs will:

• Run asynchronously in the background
• Gradually reduce version storage
• Immediately reclaim space from expired versions

Cleanup will be executed in controlled batches to minimize operational risk.

We’ll Keep You Updated

I will continue to monitor progress closely and provide updates on the storage reclaimed, the status of the cleanup jobs, and any relevant observations from the rollout. Stay tuned for follow-up insights as we share real results and lessons learned from the process.