SharePoint Version History Migration

Does SharePoint version history migrate between tenants?

Yes. Every serious migration route carries SharePoint version history across tenants, oldest version to newest, with the original created and modified dates attached. Only a manual download and re-upload flattens a file to its latest copy.

So the question people should be asking is different. Not whether SharePoint version history moves, but whether it survives the first week at the destination.

That is where projects get caught. A migration report says 40,000 files landed with full history. Three weeks later someone opens a contract and finds four versions where the source had sixty.

Which routes carry SharePoint version history?

Four routes exist between tenants and they treat version history differently. Price and scope differ too, which is covered in how to migrate a SharePoint site to another tenant.

Swipe the table sideways to see every column.

Our RecoveryTools SharePoint Migrator sits in that last row. Version history copies in full by default, or capped at a number you set per job, and the same setting covers an entire site rather than one library at a time. Moving mailboxes and Teams in the same project pulls in the Tenant to Tenant Migration Tool.

SPMT deserves a note. Its version setting has three states. Off moves the latest copy only. On keeps every version. On with a number caps the history at whatever you type in. Useful control, but SPMT reads on premises sources and cannot see SharePoint Online, so it is out of scope for tenant to tenant work. The rest of its boundaries sit in our write-up of SharePoint Migration Tool limitations.

Why do versions vanish after a clean migration?

This is the part almost nobody plans for, and it has nothing to do with your migration tool.

Microsoft added automatic version history limits to SharePoint Online as a storage saving feature. When a library runs on the automatic setting, SharePoint decides for itself how much SharePoint version history to keep: more of the recent versions, fewer of the old ones, trimmed on its own schedule.

Your tool copies 60 versions. They land. SharePoint then applies the destination library policy to them immediately. Open the file and the older versions carry an expiry note saying they go in a set number of days.

Three symptoms give it away:

• Version counts drift apart. Source and destination matched on migration day and stopped matching a month later.
• Expiry dates appear in version history. Versions show "expires in N days" at the destination that never showed anything at the source.
• It hits old versions first. The newest copies look fine, so a spot check of recent files finds nothing wrong.

What are the SharePoint version history limits now?

Microsoft reset the defaults, and the numbers decide how much SharePoint version history your destination will hold.

• New libraries default to manual limits. 500 major versions, no expiration, applied to libraries created after the policy is set.
• Manual count range at organization level. Anything from 100 to 50,000 major versions.
• Expiration has a floor. Either never, or a custom value of at least 30 days.
• Automatic mode hands the decision to SharePoint. No count to set, no expiry to agree, the algorithm chooses.

Two rules in that documentation matter more than the numbers, because teams read the settings page and assume more than it says.

First, an organization level change reaches new libraries only. Microsoft states that changes to organization level version history limits will not update the limits on existing document libraries, and applying them to existing libraries at organization level is not supported. Changes take up to 24 hours to show on new libraries.

Second, lowering a library level count does not wipe the excess at once. Versions are trimmed gradually, and Microsoft documents the pace: up to 20 of the oldest versions are purged every time a new version is created, until the library reaches its limit. A busy document loses its history quietly over a few weeks.

How do you prepare the destination library?

Five minutes of setup at the destination protects the entire SharePoint version history migration. Do it before the first batch runs, never after.

1. Open the destination library settings. Go to the library, open Library settings, then Versioning settings.
2. Set Document Version History to Manual. Automatic is the setting that trims what you just migrated.
3. Select No time limit. An expiry window silently deletes old versions on a timer.
4. Raise the count above your deepest file. Find the source file with the most versions, then set the limit higher than that number.
5. Check the organization default too. New libraries inherit it, so a site created mid project picks up the old policy.
6. Migrate one library and open a file. If no version shows an expiry note, the policy is right and the rest can run.

Tenants with hundreds of libraries do this with PowerShell rather than clicking. The cmdlet takes a count limit, a minor version limit and an expiry in days, with zero meaning never.

How much storage does version history use?

Every version occupies storage in your tenant quota. That is the reason Microsoft built automatic trimming, and it is the reason somebody in your organization will eventually ask you to turn it back on.

Answer that question with numbers rather than a policy argument. Run discovery against the source, pull the version counts, and the picture is usually lopsided: a small group of files carries most of the SharePoint version history while the bulk of the library sits on two or three versions apiece.

That shape gives you a sensible plan. Keep full history on the libraries where it means something: legal, finance and contracts. Then set a tighter count on the libraries where version 47 of a meeting agenda helps nobody. Our SharePoint Storage Analysis Tool reports those numbers per site before you argue about them.

Settle the policy during planning rather than on cutover weekend, alongside the rest of the Microsoft 365 migration planning checklist. Decide it before cutover, not after. Trimming later is the slow gradual purge described above, and you cannot bring those versions back.

Does list item version history migrate as well?

List items carry version history too, and it moves with the list on the same routes. One difference catches admins out.

The organization level version limit settings apply to document libraries, not to lists. A list keeps its own versioning configuration, so copying a library policy across your tenant leaves every list untouched. Check list versioning separately at the destination, especially on the lists that run a process rather than store documents.

Columns and content types ride along with the items. That belongs to a different topic, so this post stays on version history.

How do you verify version history landed?

A finished migration job and a complete SharePoint version history are two different claims. Check the second one directly.

• Pick your deepest files first. Find three source files with the most versions and count them at the destination, one by one.
• Open a version, do not trust the number. A version row that will not open is worse than a missing one, because the count looks right.
• Look for expiry notes. Any version showing a countdown means the library policy is still wrong. Fix it before the countdown ends.
• Confirm dates came across. Created and modified stamps should match the source, not the migration date.
• Check access while you are there. Versions are no use to somebody locked out, so pair this with how to migrate SharePoint permissions to another tenant.
• Re-check two weeks later. This is the one step teams skip, and it is the only one that catches gradual trimming.

Keep a readable copy outside both tenants while you verify, so a failed check costs an afternoon instead of a dataset. Our SharePoint Backup Tool writes that copy to local or network storage, and the SharePoint Restore Tool puts it back if you need it.

Teams without spare hands for the verification pass hand it to our cloud migration service.

Frequently asked questions

Where to start this week

Open one destination library and look at its versioning settings. That single screen tells you whether your SharePoint version history migration is safe or quietly on a timer.

Then find the file in your source with the deepest history and write the number down. Your destination count limit has to sit above it, and your storage plan has to account for it.

Two checks, ten minutes. Both are far cheaper than explaining to a legal team why a contract lost fifty versions.

Published 6 October 2026. Version limits and trimming behavior quoted above come from set default organization version limits, set version limits for an individual document library, Set-SPOListVersionPolicy and the SPMT settings reference.