SharePoint Migration Plan: 14-Week Template With Waves and Cutover
8 min read ยท 2026-10-25
A SharePoint migration plan is the step-by-step schedule for moving content from file shares, an older SharePoint Server farm or another cloud storage service into SharePoint Online and OneDrive. It covers the content inventory, the target site design, cleanup, a pilot, migration waves by department, cutover and the retirement of the old system, with an owner for each step.
Most migrations go wrong for the same reasons: everything gets copied as is, including years of duplicates and broken permissions, and users wake up on Monday to a new place they do not understand. The 14-week template below avoids that. It puts cleanup and site design before any copying, tests the approach on one department, then moves the rest in waves with a clear cutover routine and training for each group.
The roadmap at a glance
Goal: All in-scope content is in SharePoint Online or OneDrive in a structure users understand, permissions are reviewed, users are trained and the old source is read-only or retired. Duration: 14 weeks
Inventory and assessment (Weeks 1-2)
Know exactly what you are moving and what can stay behind.
- Scan each source for total size, file count, folder depth, file types and last modified dates.
- Flag issues that can block a migration, such as very long paths, unsupported characters, large files and customized SharePoint Server solutions.
- List the owner of each share, library or site and how actively it is used.
- Map permissions at the top levels to see where access is broken or inherited from old groups.
Milestone: Inventory report with size, owners, activity and blocking issues for every source, signed off by the project sponsor.
Target design (Weeks 2-4)
Decide where content will live and who can see it.
- Decide what goes to team sites connected to Microsoft Teams, what goes to communication sites and what goes to personal OneDrive.
- Design a flat site structure, with hub sites to group related sites instead of deep subsites.
- Map each source folder or site to a target site and library in a mapping sheet.
- Define permission groups per site, using Microsoft 365 groups or security groups rather than individual users.
Milestone: Approved target design and a complete source-to-target mapping sheet.
Cleanup and preparation (Weeks 3-6)
Move less, and move it clean.
- Ask content owners to archive or delete content that is not needed, using the last modified data as a guide.
- Fix long paths and invalid names flagged in the inventory.
- Create target sites, libraries and permission groups from the mapping sheet.
- Choose the migration tool: Microsoft lists Migration Manager for file shares and several cloud sources, and the SharePoint Migration Tool for SharePoint Server 2010, 2013 and 2016.
Milestone: Target sites built, cleanup done for wave one sources, and tool configured and tested on a sample.
Pilot (Weeks 6-7)
Test the full process with one department before scaling.
- Pick a small, willing department with typical content.
- Run a full migration, then an incremental pass to catch files changed since the first copy.
- Have users validate their content, links and access in the new site.
- Record timings, errors and user questions to adjust the wave plan.
Milestone: Pilot department working in SharePoint Online, with lessons learned and an updated runbook.
Migration waves (Weeks 8-12)
Move the remaining departments in planned groups.
- Group departments into waves by size, risk and business calendar, avoiding month-end or peak periods.
- For each wave, run the bulk copy a week ahead, then an incremental pass just before cutover.
- At cutover, set the source to read-only, run the final pass and redirect users.
- Deliver short training for each wave on the day of cutover, and staff a floor walker or support channel.
Milestone: Every wave migrated, validated by its content owner and working in SharePoint Online.
Decommission and adoption (Weeks 12-14)
Retire the old source and make sure people use the new one well.
- Keep sources read-only for an agreed period, then archive and retire them following your retention rules.
- Review site usage and support tickets to find teams that still struggle.
- Run follow-up sessions on sharing, co-authoring and syncing.
- Close the project with a lessons learned review and hand site governance to the owners.
Milestone: Old sources retired or read-only with an archive date, site owners trained and governance handed over.
The source-to-target mapping sheet
The mapping sheet is the most useful artifact in the project. Build it in Excel or a SharePoint list. Put one row per source location. It drives site creation, the migration tool's task list, the wave plan and the communications to content owners.
Review the sheet with each content owner before their wave. Ask them to confirm what moves, what is archived and who should have access. An owner who signs off their rows is far less likely to complain after cutover.
- Source path: the share, library or site URL.
- Size and file count: from the inventory scan.
- Content owner: the person who approves the move and validates afterwards.
- Action: migrate, archive or delete.
- Target site and library: where the content will live.
- Permission group: who gets access in the target.
- Wave and cutover date: when the move happens.
- Status and validation: not started, copied, validated.
Example: a 400-person engineering firm moving off file servers
Picture an engineering firm with two on-premises file servers, a few terabytes of project data and an old SharePoint 2013 intranet. The goal is to move everything to SharePoint Online and Teams within one quarter, before the server hardware support ends.
The decision to archive old closed projects instead of migrating them cut the copy time and made the new sites easier to browse. That decision was made in the inventory phase, when the last modified dates were on the table.
- Weeks 1-4, Inventory and design (owner: IT Infrastructure Manager, with an information architect): inventory run, a large share of project folders found to be untouched for years, hub site per business unit designed, mapping sheet built.
- Weeks 3-6, Cleanup (owner: department heads as content owners): closed projects older than an agreed date archived to cold storage, long paths fixed, target sites built.
- Weeks 6-7, Pilot (owner: project manager): HR department moved first with Migration Manager, two issues found with shortcut files and fixed in the runbook.
- Weeks 8-12, Waves (owner: project manager and IT support lead): finance, then operations, then three engineering teams one per week, intranet moved with the SharePoint Migration Tool.
- Weeks 12-14, Decommission (owner: IT Infrastructure Manager): shares read-only for 30 days, then archived, servers retired, site owners trained.
Who owns what
IT can copy files, but only the business knows what the files are. Give content owners real responsibility for decisions on their data. Give the project manager authority over the wave calendar.
Put these roles in a RACI and share it at kickoff. Content owners should know exactly when they will be asked for decisions and how much of their time the migration needs.
- Project sponsor: approves scope, timeline and the decommission date.
- Project manager: owns the plan, wave calendar, risk log and status reporting.
- Migration engineer: runs scans, the migration tool, incremental passes and error fixing.
- Information architect or SharePoint lead: site design, hub structure and permission model.
- Content owners: cleanup decisions, mapping sign-off and post-migration validation.
- Change and training lead: communications, training sessions and floor support.
- Security and compliance: permission review, retention and audit requirements.
Cutover checklist for each wave
Use the same checklist for every wave so nothing is forgotten when the team is tired by wave five. Keep it in the runbook and tick it off in the cutover meeting.
Plan cutovers for the end of a working day or a weekend, depending on how your teams work, and keep a rollback option: if validation fails, users go back to the source, which is still intact.
- Wave communication sent a week before and the day before, with the new location and training slot.
- Bulk copy complete and error report reviewed.
- Source set to read-only at the agreed time.
- Final incremental pass complete with no blocking errors.
- Mapped drives, shortcuts and links updated or removed.
- Content owner validation done on a sample of folders and permissions.
- Support channel and floor walkers ready for the first days.
How to present it to leadership
Show the six phases on a 14-week timeline with the waves as named bars, one per department. Add a status box on the right: data migrated against total, departments live against total, open blocking issues and the decommission date. Leadership mostly wants to know if work will be disrupted and if the old system will really be switched off.
Keep technical details, such as tool settings, path length fixes and error logs, in the appendix. Lead with business impact: which teams move when, how many hours of disruption to expect and what cost or risk goes away when the old servers are retired.
Risks and dependencies
Migration risks are usually about data quality, permissions and people, more than about the tool. Track them in a risk log with an owner and a fallback.
Watch for dependencies on other projects, such as a Teams rollout or an identity cleanup in Microsoft Entra ID. If permission groups depend on that cleanup, the migration waits for it.
- Oversharing copied into the new site: owner security lead, fallback is permission review per site before cutover.
- Content owners do not make cleanup decisions: owner sponsor, fallback is a default rule such as archiving content untouched for an agreed period.
- Migration slower than planned: owner migration engineer, fallback is to start bulk copies earlier and keep incremental passes small.
- Broken links in files and apps: owner content owners, fallback is a list of critical links checked during validation.
- Users keep saving to the old share: owner project manager, fallback is read-only on the source at cutover.
Common mistakes to avoid
- Migrating everything as is moves years of clutter into the new system, so archive or delete unused content in the cleanup phase.
- Recreating a deep folder tree in one giant site makes content hard to find, so design a flat structure with hub sites and separate team sites.
- Copying old permissions without review carries over oversharing, so rebuild access with groups per site and review it before cutover.
- Skipping the pilot leaves surprises for the biggest departments, so test the full process on one small team first.
- Leaving the source writable after cutover splits content between two places, so set it to read-only at cutover.
- Treating training as optional leads users back to old habits, so run short sessions on the day each wave goes live.
Frequently asked questions
How do I plan a SharePoint migration?
Start with an inventory of every source, design the target sites and permissions, clean up content, then test on a pilot group. Move the rest in waves with a final incremental pass and read-only source at cutover, then train users and retire the old system.
What tools can I use to migrate to SharePoint Online?
Microsoft provides Migration Manager in the SharePoint admin center for file shares and several cloud storage sources, and the SharePoint Migration Tool for SharePoint Server 2010, 2013 and 2016. Third-party tools also exist for more complex migrations.
How long does a SharePoint migration take?
It depends on the volume of data, the number of sources, how much cleanup is needed and how many waves you run. A mid-size organization often plans around two to four months, with most of the time spent on inventory, design and cleanup rather than copying.
Should I migrate file shares to SharePoint or OneDrive?
Use SharePoint team sites for shared team and project content, and OneDrive for personal working files. Department shares usually go to SharePoint, while home drives usually go to each person's OneDrive.
What should a SharePoint migration checklist include?
It should include the inventory, the source-to-target mapping, the permission model, cleanup decisions, a pilot, a wave calendar, a cutover checklist, communications and training, validation by content owners and a decommission date for the old system.