Version History: The Setting Most Organisations Get Completely Wrong
It’s not enough to switch it on. Here’s how to configure it so it actually protects your documents — without eating your storage alive.
Here’s something I see constantly. An organisation sets up a SharePoint site, someone ticks the “enable versioning” box, and everyone feels like they’ve done the responsible thing. Job done. Move on.
Except — it’s not done. Not even close.
Turning versioning on is the easy part. The hard part — the part that almost nobody takes the time to think through — is deciding how it should work. How many versions to keep. Whether you’re tracking major changes, minor drafts, or both. Whether settings should be consistent across the whole tenant, or tailored per site or per library. And what happens to all those old versions over time.
I’ve spent 25 years working with SharePoint. Version history is one of the most genuinely useful tools in the Microsoft 365 toolkit — when it’s set up thoughtfully. But most organisations are either leaving it completely unmanaged, or they’ve never stopped to ask: what do we actually need to keep, and for how long?
Let’s fix that.
What Is Version History in SharePoint Online?
At its core, versioning in SharePoint Online is exactly what it sounds like: every time someone edits a document, SharePoint creates a new version. This means you can see what a file looked like at any point in the past, restore a previous version if something goes wrong, and track who changed what and when.
It’s brilliant for collaboration. It’s essential for compliance. And without proper limits in place, it can quietly consume enormous amounts of storage.
Versioning settings can be configured at three levels:
- Tenant level — your SharePoint Administrator sets a global default that applies across all sites
- Site level — site owners or admins can override the tenant default for their specific site
- Library level — individual document libraries can have their own versioning rules, separate from the site
That hierarchy matters. It means you have real control — but it also means you need a strategy, not just a setting.
Major Versions vs. Major and Minor Versions
Here’s where people get confused. SharePoint gives you a choice about what kind of versioning you enable, and most people click through without really understanding the difference.
Major Versions Only
A major version is created every time someone saves a significant change to a document. Version numbers go up in whole numbers — 1.0, 2.0, 3.0. This is the right approach when you only need to track meaningful milestones, not every single edit. It’s simpler to manage and lighter on storage.
Major and Minor Versions
When you enable minor versions as well, you get a much more granular picture. Minor versions track smaller in-between changes — 1.1, 1.2, 1.3 — and typically exist in a draft state until someone publishes the document as a major version. This is ideal for content that goes through multiple rounds of review before it’s “official.”
The trade-off is storage. Minor versioning creates a lot of copies quickly. If you’re not managing limits carefully, you’ll end up with hundreds of versions of a single document sitting on your server doing nothing useful.
If your team collaborates heavily on documents before publishing — policy documents, proposals, formal reports — major and minor versioning gives you that detailed audit trail.
If you just need a safety net so people can roll back mistakes? Major versions only is cleaner, simpler, and far kinder to your storage quota.
The Three Versioning Strategies Worth Knowing
Manual Versioning
You decide the rules. At the tenant level for major versions only, the minimum you can set is 100 versions and the maximum is 50,000. You can also apply a time limit — automatic deletion kicks in once versions exceed that age. At the library level, you have more flexibility: no time limit, automatic limits, or manual count-based limits.
Manual versioning puts you in control, but it requires someone to actually think about what “control” looks like for each context — which is exactly the conversation most organisations skip.
Automatic Versioning
This is Microsoft managing the process for you. Automatic versioning uses intelligent algorithms to remove unnecessary versions based on creation date and activity. Microsoft has reported that this approach can reduce storage usage by 96% over six months compared to unmanaged versioning.
Potential storage reduction when using Microsoft’s automatic versioning — compared to unmanaged versioning over six months.
The catch: you lose the ability to retrieve every single version. For most teams doing everyday work, that’s fine. For legal or compliance teams who need a complete, unbroken audit trail, it’s not.
Short-Term vs. Long-Term Retention Strategies
These aren’t settings per se — they’re approaches you can build using the available options. A short-term retention strategy regularly purges older versions to keep storage lean. A long-term retention strategy sets high version limits and extended time periods to support compliance or archival requirements. The right choice depends entirely on the nature of the documents and the regulatory environment your organisation operates in.
Where Most Organisations Go Wrong
In my experience, there are three failure modes that come up again and again:
- Switching versioning on and never configuring limits. This is the most common one. Versioning runs unchecked, storage fills up, performance degrades, and nobody connects the dots until there’s a problem.
- Applying one setting to everything. A legal document library has completely different needs to a project team’s working folder. One-size-fits-all versioning is almost always either overkill or completely insufficient somewhere in your environment.
- Never training end users. People don’t use version history because they don’t know it’s there, or they don’t know how to access it. They create “Final_v2_ACTUALLYFINAL.docx” instead. The tool exists — but if your team hasn’t been shown how to use it, it’s solving nothing.
A Practical Framework: Matching Versioning to Purpose
| Use Case | Recommended Approach | Watch Out For |
|---|---|---|
| Legal & compliance documents | Major versions + high version limit or no time limit | Storage consumption — every version is preserved indefinitely |
| Active team collaboration | Automatic versioning or major versions with moderate limit | Can’t retrieve every single intermediate version |
| Project-based document management | Major and minor versions | Rapid storage consumption — set strict limits |
| General working documents | Major versions only, 50–100 version limit | Over-engineering it — keep it simple for everyday use |
| Publishing / intranet pages | Major and minor (minor for drafts, major for published) | Ensure only approved content is visible to readers |
Where to Start If You’ve Never Done This Before
If your organisation has never properly configured versioning, don’t panic — but do prioritise it. Here’s a simple starting point:
- Check your current tenant-level versioning settings in the SharePoint Admin Centre
- Identify your highest-risk libraries — legal, compliance, finance — and review whether their settings match their purpose
- Set version limits if you don’t have them. Even 100 major versions is a significant safety net without being reckless
- Consider whether automatic versioning is appropriate for your general SharePoint environment — the storage savings can be significant
- Show your end users where version history lives and how to access it. It takes five minutes and it changes how they work
Version history is one of those features that earns its place quietly, in the background, until the day someone accidentally overwrites a critical document and you get to be the hero who says: “don’t worry — we can get that back.”
But only if it’s set up properly.
Ready to fix the mess?
The SharePoint Cleanup Checklist: Fix the Mess Lite gives you a proven five-step process, a 30-day plan, and ready-to-send team communication templates — so you can finally build on a clean foundation. $19 USD. Instant download.
Get the Cleanup Checklist →
Hi, I’m Liza 👋
Microsoft MVP (SharePoint) • Information Architecture Specialist
I’ve been working with SharePoint for nearly two decades, across consulting and in-house roles, helping organisations design, clean up, and scale their Microsoft 365 environments.
My focus is information architecture — the layer that determines whether search works, governance sticks, and tools like Copilot actually deliver value… or quietly make things worse.
Through Simply SharePoint, I share practical, real-world guidance on structuring libraries, designing metadata, managing permissions, and fixing the issues that policies and “best practice” slides never really solve.
Everything here is based on how SharePoint is actually used — not how we wish it was used — with a strong emphasis on foundations that scale and hold up in the AI era.
