Your SharePoint Migration Probably Shouldn't Look Like Your SharePoint Farm.
SharePoint

Your SharePoint Migration Probably Shouldn't Look Like Your SharePoint Farm.

Content type Blog Post
Author Himanshi Shah
Publication Date 26 Aug, 2026
Reading Time 3 minutes

Introduction

I’ve been involved in enough SharePoint migration and Microsoft 365 projects to notice a pattern.

The biggest mistake isn’t choosing the wrong migration tool.

It’s trying to make SharePoint Online look exactly like the old SharePoint environment.

And honestly?

That’s usually the wrong goal.

🏚️ The old environment was built for a different time.

Maybe your current SharePoint farm has:

→ Deep subsites → Hundreds of libraries → Unique permissions everywhere → Old SharePoint Designer workflows → InfoPath forms → Custom web parts → Shared drives connected to libraries → Years of duplicate documents → Sites nobody remembers creating

And the migration plan says:

“Let’s move all of it to SharePoint Online.”

🚨 Stop.

This is the moment to rethink the architecture.

☁️ SharePoint Online gives you a chance to reset.

Instead of asking:

“How do we migrate this site?”

Ask:

“If we were building this today, would we build it this way?”

That one question can completely change a migration project.

A legacy approval process might become Power Automate.

A legacy form might become Power Apps.

A complicated intranet structure might become a SharePoint Hub Site architecture.

A reporting spreadsheet might become a Power BI dashboard.

A collection of manual processes might become a Microsoft 365 + Power Platform solution.

That’s not migration.

That’s modernization.

🔐 And then there's permissions.

This is where things get interesting.

I’ve seen environments where someone has access simply because:

“They’ve always had access.”

That’s not a security strategy.

During migration, it’s worth asking:

Who needs access?

Why do they need it?

Should they still have it?

Can this be managed through Microsoft Entra ID groups or Microsoft 365 groups instead?

Moving bad permissions to the cloud doesn’t make them better.

It just makes them cloud-based bad permissions. 😄

🧹 The same applies to content.

Not every document deserves a ticket to Microsoft 365.

Some content should be:

🟢 Migrated 🟡 Restructured 🔵 Archived 🔴 Deleted

A migration is one of the best opportunities an organization gets to clean up years of accumulated content.

Less content + better structure = better findability.

And when you’re thinking about Microsoft Copilot, search, metadata, governance and information architecture become even more important.

🛠️ What about ShareGate, SPMT, PowerShell and other tools?

They’re important.

Very important.

But here’s the thing:

A migration tool can move content.

It can’t decide whether your organization should still have 47 subsites.

It can’t determine whether a workflow should become a Power Automate flow.

It can’t fix your information architecture.

And it can’t create your governance strategy.

Tools execute the strategy. They don’t replace it.

🚀 My approach to SharePoint migration?

I don’t start with:

“What are we moving?”

I start with:

“What should the future environment look like?”

Then work backwards.

Discover → Challenge → Simplify → Modernize → Migrate → Govern

That’s the difference between a SharePoint migration and a Microsoft 365 transformation.

Because the best migration isn’t the one where everything arrives safely.

It’s the one where you don’t need everything to arrive.

About the author

Himanshi Shah

Microsoft 365 & SharePoint Solutions Architect & Consultant | Intranets | Power Platform | AI & Copilot Integrations | Automation | Intelligent Digital Workplace Expert

H, Shah (25/08/2026) (3) Your SharePoint Migration Probably Shouldn’t Look Like Your SharePoint Farm. | LinkedIn