Picture this.
It's Monday morning. Your migration finished over the weekend. The dashboard shows 100% complete. Success!
Then your phone rings.
"The Q3 financial reports are gone."
Your stomach drops.
You check. They're right. The files show as migrated, but they're corrupted. Unreadable. Effectively gone.
And that's when you realize: you validated that files moved. You didn't validate that they moved correctly.
This is the nightmare that keeps IT managers up at night. And it happens more often than anyone wants to admit.
Let me share some stories that will either make you grateful you haven't migrated yet, or terrified that you already have.
The Horror Stories Nobody Talks About
The scenarios below haven't happened to us personally, but they're based on real SharePoint migration issues documented in technical forums, Microsoft support cases, and IT professional experiences. We've created these composite stories to illustrate the very real technical problems that occur during migrations—problems involving special characters causing file corruption, version history failures, permission inheritance issues, and metadata loss. While the company names and specific situations are illustrative, the technical details about what went wrong are based on actual SharePoint migration failures. These stories help put into perspective what can go wrong when migrations aren't properly validated.
If you'd like to learn about our real experiences with SharePoint migrations, you can find them documented in our free ebook by GTconsult CEO, Bradley Geldenhuys, 'Planning a Successful SharePoint Migration'.
Scenario #1: The Silent Corruption
A mid-sized law firm migrated 500GB of client files to SharePoint. Everything showed as "successfully migrated." Green checkmarks everywhere.
Three weeks later, a paralegal tried to open a crucial contract from a case file. Corrupted. They tried another document. Corrupted. Then another.
They checked the entire client folder: 40% of the Word documents were corrupted during migration. They opened fine in the file list. But click them? Error message.
The kicker? The corruption happened during migration, but nobody noticed because nobody opened the files to check. They only validated that files existed, not that they were usable.
What Really Happened:
The corruption pattern was insidious. Files with certain special characters in their names—like contracts named "Müller Agreement" or "Société Contract"—transferred but became unreadable. During a similar SharePoint 2016 to 2019 migration, PDF files that appeared to transfer successfully became corrupted and unreadable. Files opened in the browser showed "This PDF document might not be displayed correctly," and downloads produced errors claiming the files were corrupted. The root cause was files with special characters—particularly accented characters like "è, é, à" in filenames—which caused corruption during the migration process while still showing as successfully transferred.
The migration tool reported success because it moved the bytes. But the encoding issues rendered the documents useless. When they investigated further, they discovered that even version history could cause silent failures—if a single historical version of a document was corrupted or problematic, the entire file migration would fail while still appearing successful in the logs.
Cost: 80+ hours of manual file recovery from backups, restoration work, and validation. Plus the panic, stress, and near-miss with a major client case.
Scenario #2: The Missing Metadata
A manufacturing company migrated their engineering drawings and specifications. All 50,000+ files made it to the new system. File count matched perfectly.
But the metadata—critical information about revision numbers, approval status, and compliance certifications—didn't migrate correctly. It was there, but in the wrong fields. Or truncated. Or just... gone.
Now they had 50,000 files with no reliable way to know which revision was current, which was approved, or which met regulatory requirements.
What Really Happened:
The metadata didn't vanish—it got scrambled. Metadata loss during SharePoint migration often results in complete loss or misplacement of metadata, where it may not be a complete loss but the earlier metadata can be corrupted if content isn't properly organized before migration. Preserving metadata like "created by," "modified by," and timestamps requires careful configuration, and some migration tools don't support full fidelity migration.
Their revision numbers ended up in the wrong custom fields. Approval statuses were truncated.
And here's the worst part: the SharePoint Migration Tool sometimes can't access files quickly enough—especially with Azure File Storage and local caching—resulting in zero-byte files with no metadata to read, but still reporting the migration as successful. They had thousands of files that looked fine in the file list but had no reliable metadata.
Cost: 6 months of manual metadata reconstruction. Multiple production delays. One near-miss on a regulatory audit.
Scenario #3: The Permission Disaster
A healthcare organization migrated patient files to a new system. Files transferred successfully. Permissions... not so much.
After go-live, they discovered that hundreds of files that should have been restricted were now accessible to anyone in the organization. HIPAA-protected patient records. Visible to people who should never see them.
The worst part? It took them two weeks to discover it. Two weeks of potential compliance violations.
What Really Happened:
The permissions didn't fail—they transformed in unexpected ways. When migration takes place from one context to another, permissions can become incomprehensible. Inconsistent or overly granular permissions lead to access issues post-migration, and mapping on-premises Active Directory users to Azure AD can be particularly tricky, especially in hybrid environments.
Files that were restricted at the folder level in their old system inherited broader permissions from parent folders in SharePoint. What should have been "Finance Team Only" became "Everyone in Organization." The wrong permission mapping during the migration process resulted in users gaining unauthorized access to important data.
Organizations under GDPR or HIPAA rules face serious consequences when migrating without properly protecting information, and any mishandling of data during migration poses significant organizational risk.
Cost: Full security audit, remediation, compliance reporting, legal review, and the perpetual fear of what might have been accessed.
Story #4: The Version History Vanish
A consulting firm migrated their proposal templates and client documents. Everything looked fine. Files were there, accessible, working.
Then someone needed to reference an old version of a document to see what changed. The version history? Gone. Every document showed as created the day of migration, with no previous versions.
Years of revision history. Proof of who approved what. Documentation of decision-making. All gone.
What Really Happened:
They thought version history would migrate automatically. It didn't. Microsoft's migration tools typically follow an "all-or-nothing" approach when transferring version history. If even a single version is missing, deleted, or unreadable due to retention policies or merges, the entire version history migration may fail.
When version history is disabled during migration (often to avoid errors), only the latest version transfers, bypassing problematic older versions. The migration appears successful, but years of revision history simply disappears.
Every document showed a creation date matching the migration date. The "Modified By" field showed the migration service account, not the actual authors. Common warnings appear in migration reports like "A file with the name already exists," which the tool uses to skip files during the first run—but version history for those files is lost.
Proof of who approved what, when decisions were made, the entire audit trail—gone. And they only discovered it weeks later when a client dispute required them to prove what changes were made to a contract.
Cost: Immeasurable. Some information simply couldn't be recovered. Client disputes became harder to resolve. Audit trails disappeared.
These aren't isolated incidents:
- SharePoint can return errors after transferring files when handling many larger files simultaneously, or when source files are corrupted, preventing SharePoint from processing them properly while migration tools still report success.
- Files stored in Azure File Storage with local caching can cause "Scan File Failure" errors where the Migration Tool sees the filename but can't access the file quickly enough, resulting in zero-byte files that appear to transfer successfully.
- During migrations, errors like "File count '74,675' is too large to create index" appear in scan summaries, though they may resolve in subsequent rounds—but users assume the first "successful" run captured everything.
The common thread? Mistakes when managing content can lead to technical glitches and data corruption that even affect customer relationships. Yet with the right tools and phased approach, businesses can experience minimal downtime and avoid these disasters entirely.
The Common Thread: "Files Moved" ≠ "Files Work"
Notice the pattern in these horror stories?
In every case, the migration appeared successful. Files were in the new location. Counts matched.
Status showed complete. Everything looked green.
The problem wasn't the migration failing. The problem was nobody verified that what moved actually worked.
It's like moving houses and checking that you moved 47 boxes without opening them to verify what's inside survived the journey intact.
The Two Types of Data Loss
When we talk about data loss in migrations, there are actually two very different problems:
Type 1: Obvious Data Loss
Files that didn't migrate at all. These are actually the good kind (if there is such a thing) because:
- You notice immediately
- Your file count doesn't match
- The migration status shows errors
- You know you have a problem
This is scary but manageable. You know what's missing.
Type 2: Silent Data Loss
This is the nightmare scenario:
- Files appear to migrate successfully
- Counts match perfectly
- Status shows complete
- But the files are corrupted, incomplete, or broken
You don't find out until someone tries to actually USE the file. Could be days. Could be weeks. Could be months.
By then:
- Your backups might be gone
- Your old system might be decommissioned
- Your trail back to working versions might be cold
- The data might be unrecoverable
Type 2 is exponentially more dangerous because it's invisible until it's too late.
Why This Happens (And Why It's Not Your Fault)
Here's the uncomfortable truth: migration tools lie.
Not intentionally. But they'll happily report "success" when all they did was move bytes from Point A to Point B.
They don't verify:
- That the file opens correctly
- That the content is intact
- That metadata survived
- That permissions are correct
- That links still work
- That formatting is preserved
- That nothing got corrupted in transit
They moved the file. That's what they were told to do. Mission accomplished.
But "moved" and "works" are completely different things.
The Anxiety Nobody Admits
Let's be honest about what you're feeling right now.
If you're planning a migration, you're thinking: "How do I make sure this doesn't happen to me?"
If you've already migrated, you're thinking: "Oh god, did this happen to me and I just don't know it yet?"
That anxiety is valid. And it's exactly why proper validation isn't optional—it's the entire point.
By The Numbers: The Real Cost of Migration Failures
The statistics are sobering:
- 68% of organizations discover redundant data costing $15k+/year ($15,000 USD / R273,000 ZAR / £12,000 GBP) in storage fees only AFTER migration. Pre-migration scanning identifies this upfront, but most organizations skip this step.
- Minor data loss incidents involving around 100 records can cost businesses between $18,120 - $35,730 USD (R330,000 - R650,000 ZAR / £14,500 - £28,600 GBP).
- Large-scale losses of 100+ million records average between $5 million - $15.6 million USD (R91 million - R284 million ZAR / £4 million - £12.5 million GBP).
- Without proper planning, migrations cause downtime or data loss leading to business disruption, and users may experience confusion or productivity dips if not properly trained on the new environment.
These aren't hypothetical costs. These are real financial impacts from real migration failures.
What Proper Validation Actually Looks Like
Most organizations do something like this:
- Run migration
- Check that file count matches
- Spot-check a few random files
- Call it done
That's not validation. That's hoping.
Real validation means:
The Security Breach Fears
Let's talk about the elephant in the room: what if your migration created security holes you don't know about?
This is a legitimate fear because:
- Permissions are complex. What worked in your old system might not translate correctly to the new one.
- Inheritance can break. A file that was restricted might suddenly inherit broader permissions from its new parent folder.
- Group memberships change. Security groups might not map correctly, giving people access they shouldn't have.
- External sharing settings. Files that were private might now be shareable externally.
The scary part? You might not find out until it's too late. Until someone accesses something they shouldn't. Until an audit reveals the problem. Until a breach happens.
This is why security validation isn't paranoia. It's due diligence.
Data Loss Is Preventable
Here's the good news: All of those horror stories were preventable.
Not with better migration tools. Not with bigger budgets. Not with luck.
With proper validation.
Every single one of those disasters happened because:
- Files were moved
- File counts were verified
- Everyone assumed success
- Nobody actually tested that everything worked
The organizations that avoid these disasters do something simple: They test that EVERYTHING migrated correctly, not just that files moved.
They validate:
- That files open
- That content is intact
- That metadata survived
- That permissions are correct
- That users can actually work
They don't just check the count. They check the quality.
The "It Won't Happen to Us" Trap
Every organization that experienced data loss thought the same thing: "Our migration will be different."
They had:
- Professional migration tools
- Experienced consultants
- Detailed project plans
- Tested procedures
And yet.
The problem isn't the tools. The problem isn't the expertise. The problem is assuming success without verifying it.
Here's the pattern:
- Migration runs over a weekend
- Monday morning, basic checks look good
- Team celebrates success
- Move on to other priorities
- Weeks later, discover the problems
- By then, it's much harder to fix
The organizations that avoid this do something radical: They assume the migration didn't work until they prove it did.
They validate everything before declaring success. They test extensively before decommissioning the old system. They keep backups until they're absolutely certain.
Paranoid? Maybe. But they sleep better at night.
What You Should Do Right Now
If you're planning a migration:
Don't just ask vendors "can you migrate our files?" Ask:
- "How do you validate file integrity?"
- "How do you verify metadata?"
- "How do you test permissions?"
- "What's your process for detecting corruption?"
- "How do we know everything works, not just moved?"
If they don't have good answers, they don't have a good process.
If you've already migrated:
You might be feeling anxious right now. That's normal. Here's what you should do:
- Don't panic. Most migrations go fine.
- But don't assume. Test a sample of your files.
- Check critical data first. Financial records, client files, compliance documents.
- Verify permissions. Make sure restricted files are still restricted.
- Test actual workflows. Have users try their normal tasks.
And keep your old system accessible for a while, just in case.
The Migration Checklist You Need
We've created a comprehensive Migration Validation Checklist that covers everything you need to verify after a migration:
- File integrity verification steps
- Metadata validation procedures
- Permission testing protocols
- Content verification methods
- User acceptance testing templates
- Security audit procedures
- Recovery planning guidance
It's the checklist we wish every organization had used before their migration. The one that would have prevented all those horror stories.
Download the Migration Validation Checklist →
Because data loss is preventable. You just have to actually prevent it.
Attend the Migration Webinar (January 13, 2026)
We're hosting a live webinar on January 13, 2026 where we'll walk through:
- Real migration disasters and what went wrong
- How to validate your migration properly
- Live demonstration of validation techniques
- Q&A with migration experts
- Free tools and templates
Plus, attendees get:
- Complete migration validation toolkit
- Testing templates and scripts
- Post-migration audit guide
- Direct access to our team for questions
Register for the Free Migration Webinar →
If you're planning a migration or recently completed one, this is worth your time.
The Bottom Line
"Everything migrated" doesn't mean everything made it.
Files can move without working. Counts can match with corrupted content. Status can show success while permissions are broken.
The only way to know your migration succeeded is to test that it succeeded.
Not assume. Not hope. Not trust the green checkmarks.
Test.
Test file integrity. Test metadata. Test permissions. Test that users can actually work.
Because the alternative—discovering problems months later when your backups are gone and your old system is decommissioned—is a horror story you don't want to live through.
Get Your Migration Validation Checklist →
Don't let your migration become the next horror story people tell to scare other IT managers.
Validate everything. Then validate again. Then sleep soundly knowing your data is actually safe.
Because that's worth the extra effort.