How to Plan a SharePoint Migration Without Losing Data or Your Sanity

A SharePoint migration is not a file copy. It's a strategic relocation of your organization's digital workplace. Every document, every permission, every workflow, every metadata tag, every integration point needs to land in the right place, working correctly, on day one. When it goes well, nobody notices. When it goes wrong, everybody notices. For weeks.

After delivering over 50 enterprise migrations across organizations ranging from 200 to 200,000 employees, I can tell you this with certainty: the migrations that succeed and the migrations that become six-month nightmares are separated by what happens before the first file moves. Not during. Before.

This guide walks you through every step of that "before." No tool-vendor bias. No theoretical frameworks. Just the practical, sequenced decisions that determine whether your migration lands clean or lands in chaos.

Why most SharePoint migrations fail before they start

The typical failed migration follows a predictable script. Someone selects a migration tool. Files start moving. Nobody mapped content to a target structure. Nobody cleaned up the source. Nobody redesigned permissions for the cloud model. Nobody planned for the custom workflows that don't translate to SharePoint Online. Nobody communicated with users. Six months later, the organization is running two parallel environments, and the original three-month timeline is a distant memory.

The root cause is almost always the same: the migration was treated as a technical task instead of a strategic project. Moving files is the easy part. Deciding where they should go, how they should be organized, who should have access, and what happens to the workflows that depend on them is the hard part. And the hard part has to be finished before the easy part begins.

Step 1: Define what success looks like before anything else

Before you audit a single document library, answer this question: what does a successful migration look like for your organization? Not technically. Strategically. Are you migrating to reduce infrastructure costs? To enable remote collaboration? To prepare for Microsoft 365 Copilot? To consolidate tenants after a merger? To modernize an intranet?

Each of these goals leads to fundamentally different architectural decisions. A migration driven by cost reduction prioritizes speed and minimal restructuring. A migration driven by Copilot readiness prioritizes clean metadata, tight permissions, and organized content. A migration driven by collaboration prioritizes information architecture and user experience. If you don't define the goal upfront, you'll make hundreds of small decisions without a consistent framework, and those inconsistencies will haunt you for years.

Step 2: Audit your current environment with ruthless thoroughness

You cannot migrate what you don't understand. A complete environment audit covers every site collection, every document library, every custom workflow, every InfoPath form, every third-party integration, every permission group, and every content type. This sounds exhausting because it is. But every shortcut taken during the audit becomes a surprise during the migration.

The audit should produce a clear inventory of your total data volume (in terabytes, not "a lot"), the number of sites and subsites, all custom code and third-party solutions deployed, all SharePoint Designer workflows still running, all InfoPath forms in active use, all external sharing configurations, your current permission model (are you using groups or direct access?), and any compliance or regulatory requirements that affect data handling.

Tools like ShareGate and Microsoft's own Migration Manager can automate much of this inventory. But the interpretation of the results requires human judgment. A tool can tell you that you have 47 unique permission entries on a single document library. Only a person can tell you whether that's intentional or a governance failure.

Step 3: Decide what you are not going to migrate

This is the step most organizations skip entirely, and it's one of the most valuable steps in the entire process. Not everything in your current environment deserves to move to the new one. Migrating stale, duplicate, and irrelevant content into SharePoint Online doesn't just waste migration time. It pollutes the new environment from day one. Search results degrade. Storage fills faster. Users lose trust in the platform because their first experience is wading through the same mess they had before.

The cleanup framework I use with every client has three categories:

Migrate: Active content that users access regularly. Current policies, templates, project files, and documents under active collaboration. This moves to the new environment in the correct target structure.

Archive: Content that's no longer active but may be needed for compliance, legal, or reference purposes. This moves to a separate archive site with restricted access and clear retention policies. It exists but doesn't pollute daily search results.

Delete: Content that serves no business, legal, or compliance purpose. Duplicate files. Outdated drafts. Abandoned project folders from three years ago. Meeting notes nobody will ever read again. Deleting this before migration is the single highest-ROI activity in the entire project.

Step 4: Design the target architecture before moving a single file

This is where you decide the structure of your new SharePoint Online environment. How many hub sites? Which departments get their own sites? How are project sites organized? Where do shared company-wide resources live? How does Teams relate to SharePoint sites? What naming conventions will govern everything going forward?

The target architecture should reflect how your organization works today and how it wants to work tomorrow, not how it was organized five years ago when the current SharePoint environment was first set up. If you're migrating from a deeply nested folder structure on a file server, this is your opportunity to flatten and simplify. If you're migrating from classic SharePoint with subsites five levels deep, this is your opportunity to move to a modern hub-site model.

The architecture decisions made at this stage determine the quality of the user experience for years to come. Get the hub-site hierarchy right, and users find content effortlessly. Get it wrong, and you've built a new maze to replace the old one.

Step 5: Map content from source to destination explicitly

Content mapping is a document (usually a spreadsheet) that says: "This content in the old environment goes to this specific location in the new environment." Every site, every library, every major folder has a mapped destination. Without this document, migration becomes an improvised exercise where different team members make different decisions, and the result is content scattered inconsistently across the new tenant.

The mapping should include the source location (old path), the destination location (new path), the data owner responsible for validating the move, any structural changes (folder to metadata, subsite to hub site), and any content that's being excluded, archived, or deleted. This document becomes the migration's blueprint. The migration tool follows it. The validation team checks against it. The project manager tracks progress using it.

Step 6: Plan your metadata strategy now because you can't retrofit it later

Moving from file-server folders to SharePoint without a metadata strategy is like moving into a library without a catalog system. The books are there, but nobody can find anything. Metadata, the labels and properties attached to documents, is what makes SharePoint search, filtering, and views actually work.

In a folder-based system, context comes from the folder path: Marketing > 2025 > Campaigns > Q3 > Social Media > Instagram. In SharePoint, that same context should be captured as metadata columns: Department (Marketing), Year (2025), Category (Campaign), Quarter (Q3), Channel (Social Media), Platform (Instagram). Documents live in flat libraries and are organized by their metadata, not by nested folders.

This transition from folder-thinking to metadata-thinking is the single biggest mindset shift in a SharePoint migration. If you don't plan for it, you end up with SharePoint libraries that are just file servers with a web interface. You've migrated the files but not the experience.

Step 7: Sort out permissions before you move anything

Permissions in on-premises SharePoint and permissions in SharePoint Online follow different models. On-premises environments often use Active Directory groups, direct user assignments, and deeply inherited permission structures. SharePoint Online works best with Microsoft 365 groups, Azure AD security groups, and a simplified, flatter permission model.

If you migrate permissions as-is, you'll carry over every inconsistency, every orphaned account, every "we gave John direct access three years ago because it was faster" shortcut. The new environment starts with the same governance debt as the old one.

The better approach: redesign permissions during the migration, not after. Map old groups to new Microsoft 365 groups. Apply the principle of least privilege. Eliminate direct user access wherever possible. Clean up orphaned accounts. Review external sharing configurations. This is the one chance you get to start clean. Taking it now costs a fraction of what a governance remediation project costs later.

Step 8: Build a plan for custom workflows and forms that won't survive the move

This is where many migrations stall. SharePoint Designer workflows, InfoPath forms, and custom solutions built with the SharePoint Add-in model do not transfer to SharePoint Online. They need to be rebuilt, replaced, or retired. With SharePoint 2013 workflows and Add-ins officially retiring on April 2, 2026, this is no longer a future concern. It's a current deadline.

The replacement path for most scenarios is Power Automate for workflows and Power Apps for forms. But the rebuild isn't one-to-one. Power Automate handles things differently than SharePoint Designer did. The migration is an opportunity to simplify overly complex workflows, eliminate redundant ones, and build modern solutions that are faster, more reliable, and maintainable by business users rather than developers.

Step 9: Run a pilot migration before the real thing

Select one department or one site collection. Migrate it completely. Test everything: content integrity, permissions, search results, workflow functionality, user experience on desktop and mobile. Gather feedback from the pilot users. Identify every edge case, broken link, and unexpected behavior.

The pilot serves three purposes. First, it validates your migration approach, tooling, and content mapping. Second, it builds internal confidence. When users see a successful pilot, they stop fearing the migration and start anticipating it. Third, it surfaces the edge cases that no amount of planning can predict. There are always edge cases. Finding them in a controlled pilot costs nothing. Finding them in a full production migration costs trust, time, and money.

Step 10: Execute the migration in phased waves not all at once

A big-bang migration where everything moves at once is a gamble. If something goes wrong, everything is affected. A phased migration, where content moves in planned waves over several weeks, is controlled, reversible, and far less risky.

Each wave migrates a defined set of content (usually one department or one functional area). Each wave is validated before the next begins. If a wave surfaces an issue, the fix is applied before it affects subsequent waves. Users transition department by department, with targeted communication and training at each stage.

Schedule migration waves during off-peak hours or weekends to minimize disruption. Communicate with affected users before, during, and after each wave. Provide a clear "where to find your stuff now" guide for every department that transitions. The goal is that no user wakes up on Monday morning confused about where their documents went.

Step 11: Validate everything then decommission the old environment

Post-migration validation is not a formality. It's the last line of defense against data loss, broken permissions, and silent failures. The validation checklist should cover content integrity (are all files present, with correct versions?), permissions accuracy (can users access what they should and not access what they shouldn't?), search functionality (do queries return relevant, complete results?), workflow functionality (are rebuilt Power Automate flows running correctly?), and user acceptance (have actual users confirmed that their daily workflows work in the new environment?).

Only after validation is complete and documented should the old environment be decommissioned. Don't rush this. Keep the old environment in read-only mode for 30 to 90 days as a safety net. If someone discovers missing content or a broken process, you can still retrieve it without a recovery project.

The 2026 deadlines you cannot ignore

If your organization is still running on-premises SharePoint, these dates define your migration window:

April 2, 2026: SharePoint Add-ins and SharePoint 2013 Workflows retire in SharePoint Online. Any custom solutions built on these models will stop working. This is a hard stop, not a gradual phase-out.

July 14, 2026: End of support for SharePoint Server 2016 and SharePoint Server 2019. After this date, no more security patches, no more bug fixes, no more technical support from Microsoft. Running unsupported software is a security liability and a compliance risk.

December 31, 2026: Retirement of Office Online Server (OOS). On-premises users will lose the ability to view and edit Office files in the browser.

If you haven't started your migration yet, the planning window is now. Migrations typically take 6 to 18 months depending on complexity. Starting in Q2 2026 for a July deadline is extremely tight but possible with the right approach and expertise.

The real cost of skipping steps

Every step in this guide exists because I've seen what happens when it's skipped. Skipping the audit leads to content in wrong locations. Skipping the cleanup leads to polluted search from day one. Skipping content mapping leads to inconsistent organization. Skipping metadata planning leads to a platform nobody can search. Skipping the permission redesign leads to a governance remediation project six months later. Skipping the pilot leads to production surprises that cost trust and time. Skipping phased waves leads to all-at-once chaos.

The organizations that migrate successfully don't have better technology. They have better planning. They invest the upfront time that others skip, and that investment pays for itself many times over in a clean, organized, adopted environment that serves the business for years.

The migration itself takes weeks. Living with the consequences of a bad migration takes years. Invest the time upfront. Your future self will thank you.