SharePoint Migration: Plan, Migrate in Waves, Cut Over Cleanly

Updated October 2026

If you are moving from file shares or an older SharePoint environment to SharePoint Online, the migration tool is the easy part. Microsoft's SharePoint Migration Tool is free and capable. Whether the project goes well depends on the work around the tool: knowing what you have, deciding where it should go, moving it in waves you can check, and planning the day people switch over.

This guide treats a SharePoint migration as a project with four stages: inventory, target structure, waves and cutover. The tool belongs to one of them.

Why migrations stall on planning, not on the tool

The hard questions in a migration are rarely technical. Which content still matters? Who owns it? Where should it live, and who should be able to see it? What happens on the morning the old share stops being the place people save files?

A tool can copy files. It cannot answer those questions. When a migration stalls, the cause is usually one of them: nobody decided what to leave behind, the target was never designed, a wave went in without checks, or people were not told where their files went.

Stage 1: Inventory and clean up before you move

Start by finding out what you actually have. For each file share, site and library, record:

• What exists: location, rough size and who owns it.
• What is stale: content nobody has opened in a long time, duplicates and old copies.
• What is sensitive: content that needs tighter permissions in the new home.
• What may not move cleanly: file names and paths that need fixing, and customizations in older SharePoint that may need rebuilding rather than copying.

Then sit down with the content owners and decide, for each area, whether it moves, gets archived or gets deleted. The point is simple: do not pay to migrate clutter, and do not carry old problems into a new platform.

Stage 2: Design a clean target structure

Decide where content will live before the first file moves. In SharePoint Online that means sites, hubs and permissions.

• Sites: give each team, department or project a clear home instead of recreating one giant folder tree.
• Hubs: group related sites so people can find and navigate between them.
• Permissions: grant access through groups rather than individuals, and name an owner for every site.

Write down the mapping from each source location to its destination site and library. That map becomes the plan for your waves and the checklist for validation. If you are also rethinking how people work in SharePoint, not just where files sit, read 5 Steps to a Successful SharePoint Modernization, which covers the redesign side in more depth.

Stage 3: Migrate in validated waves

Do not move everything at once. Split the work into waves, usually by department or by site, and start with a pilot: a willing team whose content is typical of the rest.

After each wave, validate before you start the next:

• Content arrived where the map says it should.
• Permissions match the design, not the old mess.
• Owners can open, find and edit their files.
• Issues are logged and fixed, and the fix is applied to the next wave.

Get sign-off from the content owner on each wave. Each wave teaches you something, and the later waves go smoother because of it.

Where the SharePoint Migration Tool fits

This is the stage where the tool does its job. The SharePoint Migration Tool is free and handles the copying well. Use it to move content wave by wave, and review what it reports after each run as part of your validation. Other migration tools exist, and some projects need them. Whichever tool you choose, the inventory, target design and cutover plan are still yours to do.

Stage 4: Plan the cutover and communicate it

Cutover is when people stop using the old location and start using the new one. Plan it like an event:

• Set the date and share it early.
• Run a final pass to pick up anything changed since the wave ran.
• Stop new saves to the old location so there is only one current copy.
• Tell people exactly where their files are on day one, with simple instructions for finding them.
• Have support ready for the first days, when questions come in.

A technically clean migration still feels like a failure if people open their laptops and cannot find their work.

Common pitfalls to avoid

• Lift and shift: copying folder trees as they are, so the new platform inherits the old clutter.
• Copying broken permissions: moving years of one-off access grants instead of redesigning them.
• Skipping validation: starting wave three before anyone has checked wave two.
• Surprising users: treating communication as an afterthought.

What this looks like in practice

CollabPoint has run migrations like this. For a regional grocery retailer, we moved personal drives off an overtaxed datacenter server to OneDrive for Business, more than 800 GB of content. Read the OneDrive for Business migration case study.

We also helped a banking-systems software provider move off a 20-year-old Lotus Notes system it used for email, CRM and support, rebuilding those processes on Power Platform. See the Lotus Notes modernization case study.

How CollabPoint can help

CollabPoint helps mid-market organizations plan, migrate, optimize and support Microsoft 365 across its full lifecycle. See our Microsoft 365 services and our work on collaboration and the modern workplace with Teams, SharePoint and OneDrive.

Planning a move to SharePoint Online? Talk to us about your inventory, target structure and wave plan before the first file moves.