The Migration Mistake That Costs You Six Months: Why "Lift and Shift" Doesn't Work for SharePoint

When organisations migrate file servers to the cloud, "lift and shift" is often a reasonable strategy: copy the files, preserve the folder structure, done.

Teams moving to SharePoint Online frequently assume the same approach will work here too. It doesn't, and the gap between those two assumptions is where most SharePoint migration timelines quietly double.

SharePoint isn't a file store with a web interface bolted on. It's a structured content platform built around metadata, permissions, content types, and search and a migration that treats it as a simple file-copy exercise produces an environment that looks complete on the surface while being functionally broken underneath.

Why "It Copied Successfully" Isn't the Same as "It Migrated Successfully"

A migration tool reporting 100% file transfer success tells you almost nothing about whether the destination environment actually works.

Files can move perfectly while permissions break, metadata disappears, version history is lost, and search returns nothing useful.

These failures don't show up in a transfer log; they show up weeks later, when a department tries to find a document they know exists and can't, or when someone who should have access to a library discovers they don't.

The pattern repeats across migrations that skip proper planning:

1. Broken permissions. NTFS folder permissions or on-premises SharePoint permission structures don't translate cleanly into SharePoint Online's model; copying them as-is usually recreates a permission structure that's both overly complex and subtly wrong.
2. Lost metadata. Created By, Modified By, document type, department, and retention category are exactly the fields that make content findable and governable and exactly the fields a naive file copy leaves behind.
3. Recreated folder chaos. Deep, folder-heavy structures that were already a problem on the file share get lifted straight into SharePoint, carrying the same navigation and findability issues into the new platform.
4. Search that doesn't work. Without proper metadata and content type mapping, SharePoint's search capability one of its biggest advantages over a flat file share never gets the chance to function as intended.

What a Properly Planned SharePoint Migration Actually Requires

A structured approach to SharePoint migration to SharePoint Online starts well before any content moves, with a thorough assessment of the source environment: total data volume, folder depth, permission structures, duplicate content, and, for on-premises SharePoint farms specifically, custom workflows, InfoPath forms, and third-party add-ons that may have no direct equivalent in modern SharePoint Online.

That assessment feeds directly into a pre-migration cleanup phase. Moving everything from the source environment into SharePoint Online, including outdated files, orphaned sites, and content nobody has touched in years, isn't a migration; it's relocating a mess.

Every library and site needs an owner who decides what actually moves, what gets restructured, and what gets retired before migration day.

Permissions: Where Most Migrations Quietly Go Wrong

Permissions deserve particular attention because getting them wrong has two failure modes, both of which are damaging.

Too restrictive, and people lose access to the content they need, leading to a wave of support tickets in the first weeks after go-live. Too permissive, and sensitive content becomes visible to people who shouldn't see it a problem that often isn't discovered until much later, if at all.

The right approach maps local users and security groups to Microsoft Entra ID rather than recreating every folder-level permission exactly as it existed before.

That's a deliberate simplification, not a shortcut: SharePoint Online works best with group-based access and a reduced number of unique permission structures, rather than a direct copy of years of accumulated ad hoc folder-level exceptions.



Read: Cloud Consulting Services: Transforming Your Business

The Pilot Migration Most Teams Skip or Rush

A pilot migration is where assumptions get tested before they become expensive mistakes at production scale.

Done properly, the pilot includes a realistic sample: an active department site, a document library with real metadata, a folder-heavy file share, a library with unique permissions, a few large files, and a small group of actual users testing real workflows, not just the easiest, cleanest content available.

The temptation to skip or rush the pilot is understandable when timelines are tight, but this is exactly the phase that catches problems that are cheapest to fix before production migration and most expensive to discover after production migration.

If a pilot surfaces broken permissions, missing metadata, or search issues, the answer is to fix the plan and test again, not to proceed to production and hope the same issues don't scale.

Metadata: The Difference Between "Moved" and "Migrated"

Metadata is what separates a genuine SharePoint migration from a file dump with a SharePoint interface. Created By, Modified By, document type, department, project, status, and retention category all depend on metadata being preserved and correctly mapped during migration.

Lose it, and the destination environment looks technically complete while being functionally weaker than the system it replaced search accuracy drops, compliance context disathe ppears, and workflow triggers that depended on specific metadata values simply stop firing.

For regulated or document-heavy organisations, this isn't a nice-to-have. Metadata preservation needs to be tested explicitly during the pilot phase, not assumed to have worked because the file count matches.

Choosing the Right Migration Tool for the Job

Tool selection should happen after the assessment, not before it. Microsoft's free SharePoint Migration Tool handles straightforward scenarios well file shares moving to SharePoint Online, or simple on-premises SharePoint content, where data volume is manageable and permission structures aren't overly complex.

Enterprise environments with large data volumes, intricate permissions, extensive metadata requirements, or the need for detailed migration reporting tymigration or reporting typicallysuch as ShareGate or AvePoint, which adds cost but meaningfully reduccostgration risk at scale.

Picking the tool before understanding the source environment's complexity is a common and avoidable mistake; it either overspends on tooling for a simple migration or under-tools a genuinely complex one.

What Happens After the Files Land

Migration doesn't end when the last file transfers. Post-migration validation isPost-migration project's actual success: is confirmed: testing permissions bywith real users across departments,

verify in departments turns accurate results, checking that internal links and navigatstructural changes didn't break internal links and navigationnce testing rather than relying solely on technical checklists.

A migration can pass every technical validation step and still fail from an adoption standpoint if the people using it daily can't find what they're looking for.

Frequently Asked Questions

How long does a typical SharePoint Online migration take?

Timelines vary significantly based on data volume, number of sites, permission complexity, and whether the source is a file share or an on-premises SharePoint farm. A proper assessment early on gives a realistic estimate rather than a generic industry average.

Is it possible to migrate without losing any metadata?

With careful planning and the right tool, most critical metadata can be preserved, including Created By, Modified By, dates, and document type. This should be explicitly tested during the pilot migration rather than assumed.

Should our organisation use the free Microsoft migration tool or a paid third-party tool?

It depends on source complexity. Straightforward file-share migrations withfile-sharee permissions oftmanageable permissionsosoft's free tool. Larger, more complex environments with extensive metadata and permission requirements usually justify the cost of a dedicated third-party tool.

What's the single biggest predictor of a failed SharePoint migration?

Skipping or rushing the pilot migration phase. It's the stage specifically designed to surface permission, metadata, and search issues while they're still cheap to fix, and teams that skip it tend to discover the same problems at a much more expensive, disruptive scale during production migration.