By default, Microsoft ships with 500 major versions per file and no file version expiration, but most Microsoft 365 tenants haven't changed their version history defaults. That adds up fast in any document-heavy environment, where one 10MB file can use up to 5GB of total storage.
The SharePoint admin center gives you a tenant-wide lever to set version history limits across the tenant. What's less obvious is what that lever controls. The change only applies to new libraries going forward. Every document library that existed before you made the change is still running at 500 versions.
That distinction matters, and most walkthroughs on this topic skip it. Both sides are covered here: the steps to set the org-level limit, and what you still need to do about the libraries that already exist.
SharePoint's default of 500 major versions per file applies to every document library in your tenant unless you've explicitly changed it. There's no expiration date; versions don't age out on their own.
Five hundred versions sounds like a generous buffer until you think about what generates them: a contract through ten rounds of negotiation, a budget spreadsheet touched by four people across six weeks, a policy document reviewed every quarter. Each save creates a version, and each version consumes full file storage for that copy.
For a closer look at how that accumulation lands on your storage bill, see how version history bloats SharePoint storage. Before you start changing settings, it's also worth reviewing how to check SharePoint and OneDrive storage across the tenant to understand your baseline.
The org-level version history setting lives in the SharePoint admin center. You'll need SharePoint administrator permissions to make this change.
Before committing to a limit, consider running a version storage usage report first. Microsoft's New-SPOSiteFileVersionExpirationReportJob generates a per-site estimate of how many versions would be deleted and how much storage would be reclaimed, which is useful context before applying a change across a large tenant.
Steps:
One warning before you save: when SharePoint enforces a version limit and removes older versions to stay within it, those versions bypass the recycle bin and are permanently deleted. There's no recovery path, so set your limit with that permanence in mind.
The two modes take different approaches to version storage.
Automatic mode uses Microsoft's intelligent versioning algorithm, which retains versions on a time-based thinning schedule up to a maximum of 500 versions total across all time buckets:
Automatic mode is Microsoft's recommended default for most tenants. It keeps the versions most likely to matter and progressively thins the rest without requiring a fixed count decision.
Manual mode sets a fixed count of major versions (100–50,000). Use Manual if your compliance program specifies a defined version window, or if your auditors expect a consistent count across libraries. A fixed number is easier to document and defend than an algorithm.
If you're managing a large tenant or scripting this change as part of a configuration baseline, PowerShell is the better path.
To enable Automatic mode tenant-wide:
To set a fixed major version count:
To apply a version policy to existing libraries within a specific site, combine a version limit parameter with -ApplyToExistingDocumentLibraries.
For Automatic mode:
For Manual mode:
Microsoft's versioning tutorial covers all of the above, plusNew-SPOSiteFileVersionBatchDeleteJobfor submitting bulk version delete jobs at the site level.
Full script:
After running the above script, this is what you'll see in the admin center:
This is the part the admin center doesn't surface prominently.
The version history limits setting controls the default behavior for document libraries created after the change. Libraries that existed before you changed the setting retain whatever limit was in place at creation. If your tenant's previous default was 500 versions, every pre-existing library is still running at 500 versions regardless of what you set today.
Version limits are enforced incrementally, not as an immediate purge. When a limit applies to a library that already contains versions, SharePoint doesn't delete existing versions on the spot. Instead, the oldest versions are removed one at a time as new saves push the count over the limit. Clearing an existing backlog in bulk requires an explicit batch delete job.
Retention-policy gotcha: If a document library is subject to a retention policy or eDiscovery hold, version limits and version trimming are both ignored for held items. The hold takes precedence over the version limit. This is a common production surprise: version cleanup runs, storage barely moves, and the reason is a retention policy scoping in more libraries than expected. Confirm your retention scope before assuming cleanup will run across all libraries.
The tenant-level default is the starting point, but individual libraries can override it. The precedence order runs from most specific to least: library settings override site settings, which override the tenant default.
To adjust versioning at the library level, navigate to the library → Settings (gear icon) → Library settings → Versioning settings. The library-level version settings use the same Automatic/Manual options, and they apply only to that library. This is the right path when a specific library needs to behave differently: a legal document library that warrants longer retention, or a high-churn workspace that needs a tighter ceiling.
Setting new limits for future libraries stops the problem from growing. The libraries already in your tenant are a separate problem, and they're often where the actual storage cost lives.
The native approach works site by site: run Set-SPOSite with -ApplyToExistingDocumentLibraries per site, or submit New-SPOSiteFileVersionBatchDeleteJob for each site's version debt. For a handful of sites, that's manageable. Across hundreds or thousands of SharePoint sites, each with multiple document libraries, it becomes a significant operational effort with no clear audit trail across the whole tenant.
Orchestry's version cleanup can run bulk version purging jobs across existing document libraries. You apply a Workspace Review policy to a workspace, provisioned through Orchestry or not, and define a one-time cleanup, a maximum version limit going forward, or both. Users can configure the number of versions to keep (by date or by count) and which libraries to skip. Orchestry runs the purge and storage reclamation shows up in days through Microsoft's API. Orchestry's cleanup targets major versions, which is where the storage accumulation actually lives for most tenants.
One scope constraint to be aware of: Workspace Review policies apply to team-connected workspaces only. Classic sites, non-group-connected sites, and communication sites aren't covered by this approach.
The admin center sets a defensible default for libraries created going forward. Orchestry's Workspace Reviews give you the operational layer for what already exists: visibility into which workspaces are carrying version bloat, the ability to trigger bulk cleanup across those workspaces, and a record of what ran and what storage was reclaimed.
That combination is what a complete version history strategy looks like: set the org-level default in the admin center to stop the accumulation from continuing, and use Orchestry to work through what's already there.
If your tenant has been running the 500-version default for years, the backlog is where the actual storage cost lives. A new org-level default stops the accumulation; clearing the existing backlog is what closes the gap. After applying the org-level default, confirm the change was logged in the Microsoft Purview compliance portal. The audit log records org-level limit changes, which is useful for internal audit trails and confirming the change applied as expected.
Orchestry automates version cleanup across your existing libraries. If you'd rather not work through this site by site, start a free trial or book a walkthrough.