How to build a SharePoint migration plan

TL;DR: Avoid the never-ending migration cycle by building a clear plan first: define what a successful migration looks like, sort every site into Remove, Migrate, or Rebuild, take full inventory of your environment, and prioritize what moves when.

So, you've decided to go ahead with a SharePoint migration—or someone higher up decided and you've inherited the project.

Whatever kind of migration you're planning, if you're here, it's because you're ready to get started. But where should you start? What should you do first? And how should you actually do it?

A big thing has changed: SharePoint Server 2016 and 2019 reached the end of extended support on July 14, 2026. If you're still running either of those (or anything older), you're now on unsupported software—no more security updates. The modern destinations are SharePoint in Microsoft 365, or SharePoint Server Subscription Edition if you genuinely need to stay on-premises. For most organizations, the cloud is where this story ends up.

Here at ShareGate, we've spent a lot of time thinking about the steps involved in a successful migration—especially as we keep improving our migration tool. And the one thing we've learned over and over: a detailed plan answers these questions before they turn into 2 a.m. problems.

‍

Create a SharePoint migration plan template

What is a migration plan template? I could pull out a definition from a sophisticated source or we could try to define it together.

Basically, a template is exactly what it sounds like: we're identifying the milestones we want to achieve before arriving at our destination.

But before we begin the template, we obviously need to know what our destination is.

Define a successful migration

Before we create any sort of plan for our migration, we should know what to expect after the project is over.

The first thing you need to do is define your organization's criteria for a successful SharePoint migration. When do you expect the migration to be complete? What content should absolutely be moved? Should it be branded? Etc.

Use the RMR strategy (Yes, I just invented that)

Before we can create our template, we need to know what we’re going to migrate.

At ShareGate, over the course of our many migrations, we created a strategy we like to call RMR.

Remove, Migrate and Rebuild.

Remove

These are the sites you're not moving. Note the word "remove"—it's deliberate. It means you're explicitly deleting this content, or deliberately leaving it behind on the old environment to be decommissioned. The point is: it does not come with you to the new destination. Every migration is also a spring cleaning, so be honest about what's actually still used.

The idea is that these sites will not be moved to the new SharePoint destination.

Migrate

These are the sites that are coming along. How? That's up to you. Choose the migration approach that best fits your organization.

If you're moving from on-premises to Microsoft 365, Microsoft's free SharePoint Migration Tool (SPMT) handles SharePoint Server 2010, 2013, 2016, and 2019, plus file shares—moving content into SharePoint, OneDrive, and Teams.

For bigger or ongoing jobs, Migration Manager lives right in the SharePoint Admin Center and lets you run agent-based migrations at scale. Both of those can be driven through PowerShell if you'd rather script it.

Or, you can use ShareGate to move your sites, lists, libraries, and permissions with a lot more control and a lot fewer surprises. Again—how you migrate is your call.

Rebuild

Sometimes the right move is to rebuild the site fresh at the destination. This usually happens with heavily customized sites built on old architecture—classic full-trust solutions, retired web parts, legacy workflows.

With modern pages, web parts, Power Platform, and the way the modern experience is designed to work, there are usually a few sites that either won't come over cleanly or simply deserve a do-over to take advantage of what's available now. Rebuilding isn't a failure—it's often the upgrade.

Learn SharePoint Online: Best practices, tips, and tricks

‍

Building your SharePoint migration plan

Now that you know what RMR is—and you've sketched your own template with it—you're ready to build the actual plan.

You could create a gorgeous visual plan in Miro, Visio, XMind, or whatever you like. But my method is a little more hands-on… I use SharePoint itself.

Wait, what? No, I'm not drawing anything. I create a SharePoint list to track every site affected by the migration.

My goal here is to list all the affected sites and tag each one as Remove, Migrate, or Rebuild—plus note whether that action is approved and when it's scheduled.

‍

1. Create the SharePoint list.

I made a list called Migration Roadmap with rows for site title, URL, migration action, owner, approval status, and target date. Then I drop in every site from the environment I'm migrating from.

Don't have an inventory yet? Before you migrate, it's worth running the SharePoint Migration Assessment Tool (SMAT)—a free command-line scanner from Microsoft that checks your farm for issues you'll want to fix before they bite you mid-migration.

If you want a richer, friendlier read on your environment, ShareGate's pre-migration reports do this too (more on that in a second).

For a raw inventory, PowerShell is still your friend. I use the following command:

Get-SPWebApplication https://intranet.contoso.com | Get-SPSite -Limit All | Get-SPWeb -Limit All | Select Title, URL, ID, ParentWebID | Export-CSV C:siteinventory.csv –NoTypeInformation

On-premises you can pull sites with the SharePoint Management Shell, and for Microsoft 365 the PnP PowerShell module makes exporting a site inventory to CSV quick and painless. Either way, export it, and you've got the raw material for your roadmap. (You can even feed that CSV into Visio to auto-draw a diagram, if visuals help you sell the plan upstairs.)

I set the Migration Action row to three choices—Remove, Migrate, Rebuild—and I turn on content approval so the business has to sign off whenever something gets flagged as Remove. Nobody likes finding out after the fact that their site got deleted.

‍

‍

‍

2. Add your content to the list to create the plan

Of course, the list would be a lot longer in a non-fictional organization.

In a real organization this list gets long—but that's the point. This is your migration plan now. Export it, build custom views, filter it for a manager or for the team doing the work. Everything you need lives in one place.

From here, you Remove, Migrate, or Rebuild each site.

But it won't always fit neatly into those three buckets, and that's okay. Modern features, new web parts, and a shift to the modern experience will change how some of your architecture should look. A lot of that lands under Rebuild—fine. The important thing is to adapt the strategy to your needs, not force your environment into mine. Take the time to analyze what you've actually got before you move everything over "as is."

‍

Understand your inventory

The single most important pre-migration step is taking inventory of your current environment. This will help you make better decisions about what to migrate and how long it will take to upgrade your end users into their new environment.

You need to know what’s under the hood, and ShareGate can help.

Using ShareGate, you can run a source analysis to determine things like:

• the size of your environment 
• the size of your file shares 
• the number of site collections 
• the number of sites  
• the number of unused or abandoned sites  
• the number of files and folders 
• the number of workflows 
• Potential issues

‍

After scanning, you get a quick summary of what you have, plus the warnings and errors you're likely to hit. It's perfect for sizing up how big and complicated the job really is—a great way to estimate effort, and available in ShareGate's trial without limits.

‍

Prioritize how to tackle your plan

A few things to nail down before you execute:

• Who owns the Remove portion of the roadmap?
• Who owns Migrate?
• Who owns Rebuild?
• What's the approval workflow for each action—and who's approving?
• Who's meeting with site owners, and is that the same person running the action?

I like to build a simple points system to assign business priority to each site—usually a mix of how engaged a team is with SharePoint (did they take the training? are they actually excited to use it?) and how many people the site affects. That combination makes it obvious what to tackle first.

You'll absolutely come up with other factors based on your own organization—no two migrations are ever the same.

What I can't stress enough: you need a plan and a roadmap. Otherwise you'll get stuck in the never-ending migration cycle where, eventually, someone throws up their hands and says, "That's it."

Now that you know how to build the plan, the next thing worth your time is understanding how to avoid the common pitfalls once you start moving content.