Migration
What should be validated after a SharePoint migration?
Quick answer
Post-migration validation should check content counts, failed or skipped items, metadata, versions where required, permissions, sharing, folder structures, links and business-critical functionality. Large migrations should use automated validation wherever practical rather than relying entirely on manual checks.
Key takeaways
- Compare counts, metadata, permissions, and exceptions — not just spot checks.
- Agree version/timestamp mappings before sign-off.
- Require business-owner acceptance per wave.
Detailed Explanation
Post-migration validation should check content counts, failed or skipped items, metadata, versions where required, permissions, sharing, folder structures, links and business-critical functionality. Large migrations should use automated validation wherever practical rather than relying entirely on manual checks.
How it works
Compare source vs target: file/folder counts, sizes, metadata columns, version counts, permission mappings, and exception reports from the migration tool. Re-run deltas, then have business owners open top libraries, test search, and confirm sharing still works.
Limitations and considerations
Spot-checking 5 files is not validation. Version history, timestamps, and created-by fields often map differently by design — agree expected mappings before sign-off so differences are not misread as data loss.
For broader context, see the Migration Hub — it collects the guides around this topic.
When to use it
Use after every migration wave — pilot, bulk, and delta — before closing the wave and releasing users to the target.
Practical example
After a file-share move, a team compares 12,400 source files to 12,382 targets, resolves 18 blocked long-path files, confirms metadata views filter correctly, and gets library-owner sign-off before cutover.