Nobody arrives at university planning to gain fifteen pounds. What happens is that the workload arrives first. Coursework stacks up, deadlines move, and the hour that used to go to the gym becomes the hour you finish the assignment. The Freshman 15 isn't a decision anybody makes. It's the residue of every week where something more urgent won.
A tenant gains weight for exactly the same reason. There's always a migration, an incident, a rollout, or an audit, and every one of those arrives with a date attached. Reviewing what's actually sitting in SharePoint never does, so it slips to next quarter, every quarter. And in the meantime the thing that review would have caught keeps growing. Somebody starts a project, so somebody creates a Team, which quietly provisions a Microsoft 365 Group, a SharePoint site, and the libraries underneath it. Add a private channel and you've got a second site. Every edit to every file in any of them writes another version. Nobody decides to keep three copies of the same proposal across two sites and a chat, it just accumulates, one reasonable action at a time. It stays invisible because the work that would make it visible is the work that keeps getting postponed.
For years this was a line item on an invoice. Now it's something else. In our State of Microsoft 365 Governance Report 2026, a Censuswide survey of 327 IT and security decision-makers at organizations of 500 or more employees, 76% have already deployed or piloted Copilot or another enterprise AI tool that reads their Microsoft 365 data. That content isn't just sitting there costing money anymore. It's being read, ranked, and served back to your users as answers.
Every number below comes from practitioners estimating their own environments rather than from tenant scans, and self-assessment tends to flatter, so treat them as a floor.
Ask an admin why storage grew and you'll usually hear "users upload a lot." That's part of it, but three quieter mechanisms tend to do more damage, and none of them involve anybody uploading anything.
Most tenants are running a setting nobody chose. The default version history limit for your organization is 500 major versions with no expiration. Not 5, not 50. Up to five hundred versions of every file, kept indefinitely, and every one of them consumes storage you pay for.
Then there's AutoSave, which is on by default for files in SharePoint and OneDrive and keeps writing new versions while people work rather than waiting for somebody to press save. A file that a team edits every week accumulates versions far faster than anyone watching the folder would guess, and on a large file the version history can end up consuming more storage than the current copy does.
Five hundred versions, never expiring, and read the line above the options: this setting does not apply to existing libraries. Microsoft tells you the catch right there in the panel.
Sites are easy to create and nobody ever comes back to close one. The project finishes, the owner moves on or leaves the company, and everything that was provisioned alongside it carries on existing with nobody accountable for any of it. In our research, 47% of respondents named workspaces with no active owner among their governance challenges, more than any other issue in the study, and 92% estimate they're carrying at least some right now. A further 24% named uncontrolled site sprawl specifically.
This is the newest ingredient and the least discussed. Generative tools produce first drafts, variations, and summaries faster than any team could before, and that output lands in the same libraries as everything else. It also tends to be larger, because AI-assisted documents arrive fully formed rather than growing from a paragraph.
That's an observation rather than something we measured, but the direction is hard to argue with: the tool most organizations bought to make sense of their content is also, quietly, producing more of it.
This compounds because almost nobody is watching continuously. Asked how they monitor SharePoint storage, respondents described a toolkit of point-in-time views: 62% use the SharePoint admin center site storage view, 50% run PowerShell scripts to pull the data, and 41% use native Microsoft 365 storage reports. There's nothing wrong with any of those, except that every one of them needs somebody to remember to go and look.
And it shows. Only 19% say they actively manage storage and have never been close to their limits. Everyone else has been surprised or nearly surprised: 52% received warnings and dealt with it before hitting the limit, and 27% hit the quota and had to buy more storage.
That's 79% of organizations learning about their own growth from an alert rather than from a plan.
Sorting Active sites by storage used is the fastest way to find where the weight is. It's also the report most teams open for the first time only once something has gone wrong.
What that alert costs you is easy enough to work out. Your tenant gets 1 TB of SharePoint storage plus an allowance per licensed user, though not every license type contributes to that pool, which is worth checking if you have a lot of frontline staff. Past the limit, storage runs about $0.20 per GB per month, so a terabyte of overage is roughly $200 a month, or $2,400 a year, for content nobody has opened.
That number is also your best argument internally. Asked what would unlock investment in governance tooling, 43% of respondents named demonstrated cost savings, second only to a leadership mandate. Storage is the one governance problem you can take to a budget conversation without asking anyone to imagine a breach.
Everything so far has been about money. This part isn't.
Microsoft 365 Copilot grounds its answers in your content, and it's good at that. Give it four near-identical drafts of the same proposal, a policy that was quietly superseded in 2023, and a budget spreadsheet somebody abandoned halfway through, and it has no reliable way to tell you which one your organization actually stands behind. It can often work it out from context, and it frequently does. But it's ranking by relevance, not by currency, and the more duplicates you give it the more often it picks the wrong one.
In my experience this is the most common reason people come away unimpressed with Copilot, though I'll flag that as a pattern I see rather than a survey finding. The model is usually working fine. It's answering accurately from a corpus nobody has curated in a decade.
And the trust cost is asymmetric. A user who gets one stale answer doesn't conclude that the 2019 budget draft should have been cleaned up. They conclude that Copilot is unreliable, and they stop asking it things. You can spend $30 per user per month and lose the rollout to content hygiene.
Most organizations, once they see the number, reach for one of two fixes. Both feel like progress. Neither does what people expect.
Switching the version limit to Automatic does nothing to what you already have. Microsoft's automatic version history limits are genuinely good: the algorithm keeps everything for the first 30 days, then hourly versions out to 60 days, daily versions out to 180, and weekly versions beyond that, which Microsoft's own documentation puts at up to a 96% reduction in version storage over six months compared with count limits alone.
But read the fine print carefully. Changes to organization-level version limits apply only to libraries created after the change. Existing libraries keep their old limits. And the change never trims versions that already exist. You've changed what you eat. You haven't lost a pound.
Archiving doesn't trim versions either. This one catches almost everybody. Microsoft's documentation is explicit: archived files retain all versions, all versions are restored on reactivation, and versions can't be archived independently of the file. So if you archive a document carrying 400 versions, all 400 go into cold storage with it, and you pay the archive rate on the whole lot.
Archiving does cut the bill, just not where most people go looking for the proof. Moving data into the archive tier takes it out of active storage, and only active storage counts toward your tenant quota. What doesn't change is the individual site's usage towards your quotas if you have any, because sites keep counting archived files exactly as they counted them before. The savings are real, they show up at tenant level rather than on the site you archived from.
The sequence matters more than any individual step, because doing these in the wrong order means paying cold-storage rates on content you were about to delete.
You don't have to guess at any of this. SharePoint can produce a version storage report that lists every version on a site with its size, so instead of estimating what version history is costing you, you get the actual number. Microsoft then provides What-If scripts that run against that same report and model what each version limit would have done, before you commit to anything.
Neither of these is a button in the admin center. Both are PowerShell, and the What-If scripts need PowerShell 7 specifically rather than Windows PowerShell, which is where most people get stuck. The report is also slow, taking over a day on a small site and several days on a large one, so start it well before the meeting where you need the number.
Measure before you cut. Trimmed versions do not come back.
Set the organization default to Automatic so new libraries start healthy, then go after the existing ones, which is where the weight actually is. You'll need SharePoint Administrator for both:
# New libraries across the org. Does not touch anything that already exists.
Set-SPOTenant -EnableAutoExpirationVersionTrim $true
# Existing libraries on one site. Start here, not tenant-wide.
Set-SPOSite -Identity https://contoso.sharepoint.com/sites/ProjectX `
-EnableAutoExpirationVersionTrim $true -ApplyToExistingDocumentLibraries
Trimming permanently deletes versions, and that's worth sitting with before you run the second command. A user deleting a version by hand can recover it from the recycle bin. Versions removed by a policy or a trim job bypass the recycle bin entirely and are gone unless you're running Microsoft 365 Backup. Pilot it on a site you own before it goes anywhere near a library somebody depends on.
The storage also doesn't come back the moment you press enter. Applying new limits to existing libraries runs as a background job worth watching rather than assuming, and where you lower a count limit on a library, Microsoft trims the excess gradually, purging up to 20 versions per file each time that file is next updated. Expect the number to improve over weeks. Track progress with Get-SPOSiteVersionPolicyJobProgress and stop a job with Remove-SPOSiteVersionPolicyJob.
With versions trimmed, archiving stops being expensive storage for junk and starts being real savings at $0.05 per GB per month against the $0.20 standard rate, a 75% reduction. Start with site-level archive for whole sites nobody works in anymore but that you can't delete: the finished project you may need to refer back to, the closed department, the acquisition that completed three years ago. Then use file-level archive for the stale content sitting inside sites people still use every day, which is usually where the bulk is hiding.
Microsoft 365 Archive runs on pay-as-you-go billing tied to an Azure subscription, so turning it on is a conversation with whoever owns your Azure tenancy rather than a setting you flip on just in the admin center. Once it's on, file-level archive is enabled by default for every SharePoint site. The guides linked above cover the rest, including the setup walkthrough, who needs which permissions, reactivation timings, and the limits worth knowing before you roll this out to users.
Tell your users before you start. Archived files don't behave normally in Word for the web, on the mobile apps, or through the OneDrive sync client yet, and a user who meets a confusing error on a file they need will open a ticket rather than work out that it's archived.
Archived files stay where they were, with a badge. Users don't lose the folder structure they know.
Archiving also does something the invoice doesn't show. Archived content drops out of what Copilot can retrieve and ground its answers on, which is why Microsoft lists Copilot optimization as one of the benefits of Microsoft 365 Archive. Every stale file you move out is one less candidate for a confidently wrong answer.
None of this holds without somebody accountable for the content. Enforce a two-owner minimum on new workspaces, and if you're licensed for SharePoint Advanced Management, put its site lifecycle policies to work so inactive sites get flagged to their owners rather than discovered during a quota panic.
Some of this content isn't yours to clean up, and that's worth understanding before you promise anyone a number.
Where a retention policy or an eDiscovery hold applies, SharePoint ignores your version limits entirely. Not reduces them, ignores them. A trim job that meets held content stamps an expiration date on it and moves on, and documents marked as records have version deletion blocked outright. For a bank or a hospital, a meaningful share of the version history you just measured is simply not removable, and any savings estimate that assumes otherwise will be wrong in the direction that gets noticed.
That's an argument for archiving rather than against it. Archived content keeps its retention policies, sensitivity labels, and eDiscovery reach, and Purview can still search and export it. So for regulated content the move was never deletion. It's to stop paying active storage rates to keep something you're legally obliged to hold on to anyway.
The Freshman 15 isn't really about food. It's about what gets dropped when everything else is urgent, and about how long it takes to notice. Nobody skips one workout and gains fifteen pounds. They skip it for a term because there's always something due, and the result only shows up long after the habit formed.
Tenants are the same, which is why a cleanup project is the wrong shape of answer. Cleanup projects end. The accumulation doesn't. What actually holds is a sensible default, a policy that runs without anybody remembering it, and somebody whose job description includes caring about this.
You can't out-archive a content problem you're still creating. But you can stop adding to it today, and the first honest look at your own version storage is usually all the motivation anybody needs.