6 steps to prepare your SharePoint 2016/2019 migration before the 2026 deadline

Plan your SharePoint Online migration the right way by assessing, cleaning up, and building a structured roadmap before Microsoft’s 2026 deadline. Microsoft MVP Richard Harbridge shares practical steps IT pros can use to avoid risks, reduce downtime, and keep projects on track.

Migrating from SharePoint Server 2016 or 2019 to a modern platform—whether that's SharePoint Online, SharePoint Server Subscription Edition (SPSE), or a hybrid of both—is a multi-phase program, not a one-time task. It’s a multi-step process that requires careful preparation, planning, migration, and modernization.

Why invest time upfront?

• Time is limited: Extended support for SharePoint 2016 and 2019 ends July 14, 2026. After that, no more free security patches.
• Unplanned projects cost more: Poor planning can inflate migration effort, timelines, rework and cost.
• Hidden risks derail projects: Poor and incomplete inventories miss customizations, forms, workflows and legacy that later break in SharePoint Online or SPSE.

This article is part of an in-depth blog series designed for IT pros who want practical, detailed guidance on every step of the migration journey. I'll break down how to prepare your environment, assess and clean up content, choose your destination, and build a migration plan that keeps your project on track.

‍

Want the key takeaways? Download our eBook for a checklist-driven approach to planning.

‍

Step 1. Assess your source environment and identify issues

The first step is to take a full inventory of your SharePoint environment.

For SharePoint 2010, 2013, or 2016 environments, Microsoft’s SharePoint Migration Assessment Tool (SMAT) is a good place to start. It's a lightweight command-line scanner that runs in read-only mode and outputs logs highlighting customizations, large lists, unsupported site templates, and other elements that may need attention before migration.

Running SMAT (or an equivalent tool) early gives you a clear picture of what complexities lie in your environment, from heavily customized sites to workflows, so you can plan for them rather than be surprised mid-migration.

Tip: SMAT reports provide a lot of detail but also many false positives. If you’ve never reviewed them before, it’s important to know what you can filter out and what needs further review.

Good to know

• SMAT doesn’t support SharePoint 2019. If you’re migrating from SharePoint 2019, I recommend a script-based assessment (PowerShell/CSOM) or a third-party tool to analyze sites, lists, features, and customizations.
• Scripts or tools should always be used to augment and enhance your assessment. This can provide actionable insight into areas like permissions complexity and patterns across existing site collections, subsites, and libraries that SMAT doesn’t include. This can help with simplification, mapping permissions to Microsoft Teams’ simplified model, and providing additional context for scoping validation and testing before, during, and after migration.
• Legacy, deprecated and unsupported elements matter. Identifying these major risks that may require rebuild or business decision support early is important. Example: SharePoint 2013 workflows retire in Microsoft 365 by April 2, 2026, and InfoPath Services retire after July 14, 2026 — replacements must be planned.

By running these assessments, you’ll have the information needed to prepare your source, align scope, and plan for a more seamless migration.

Quick tips for assessment

• Export an inventory of all sites and site collections (via PowerShell or a third-party tool like ShareGate) and classify each for migration. Many organizations use a spreadsheet or SharePoint list as a migration tracker.
• Know what will be included in the migration. Exclude old, orphaned, or unused collections where possible.
• Look beyond data size: assess the number of items, files, folders, structural objects, and data complexity.
• Pay attention to your permission structure. Identifying areas for optimization or remapping permissions early can improve security and governance in the destination.
• Identify solutions early. A solution is a set of customized pages, workflows, and forms that work together. Tackling them holistically results in more successful migrations than addressing each component in isolation. You should map solutions to users and owners internally to help with future validation post migration and to help answer questions around scope in case it could be left behind, saving time in the assessment and migration.

Step 2. Audit content and clean up ROT

Migrating is also an opportunity to clean house. Many legacy SharePoint environments have years of redundant, outdated, or trivial content—often referred to as ROT.

A content audit helps identify inactive sites, obsolete documents, duplicate files, and old list data. Removing or archiving this content reduces the volume to migrate, improves performance, and lowers storage costs in your new environment.

One effective technique is the remove, migrate, rebuild (RMR) strategy:

• Remove: Delete, archive or exclude redundant, obsolete, or trivial content (while respecting retention). For example, unused team sites or outdated solutions. Removing ROT upfront minimizes digital clutter in your new environment.
• Migrate: Move current, active content that users still rely on. Don’t worry about being overly conservative—you can always optimize later in the destination.
• Rebuild: For complex or customized solutions that don’t translate well to the new platform, plan to rebuild them. This often applies to InfoPath forms, workflows, custom applications, or heavily scripted sites. Rebuilding in the modern environment allows you to take advantage of new architecture and features (Modern Libraries, Lists & Pages, Power Apps, Power Automate, Copilot, SPFx and etc.).

Involving business owners in this process is key. They should sign off on anything that’s archived or excluded. Some may even take ownership of cleaning up their content in advance. Consider making content owners accountable; enabling an approval step for any content slated for removal to avoid surprises during cutover.

Step 3. Understand your destination

The next step is deciding whether to migrate to SharePoint Online or upgrade to SPSE.

Microsoft recommends moving to SharePoint Online whenever possible. SharePoint Online offers evergreen updates, modern user experiences, integration with Teams, Copilot, and the Power Platform, as well as reduced infrastructure overhead.

If regulatory or business constraints prevent a cloud move or you're not ready for full cloud, SPSE on-prem and hybrid (SPSE + M365) is the alternative. It brings modern UI, improved support, and lifecycle enhancements while still running in your datacenter. Hybrid can enable cross search, profiles, and phased content moves. For SharePoint 2016 or 2019, Microsoft supports a direct database attach upgrade to SPSE. In practice, this involves setting up a new farm, migrating services, copying and mounting content databases, and upgrading sites. Trial upgrades in non-production environments are highly recommended.

‍

Licensing note: SPSE requires eligible licensing/Software Assurance — validate entitlement early.

Key point: Even if you stay on-prem with SPSE, plan for a cloud-ready architecture. Many modernization steps, such as cleaning up subsites or replacing workflows, apply equally to SPSE.  

While subsites won’t block a migration (while a broken workflow will) modern architecture guidance is clear: avoid subsites; flatten these as site collections and use hubs that way you benefit from better governance, experiences and ‘team ready’ alignment. Here is additional guidance on how to “teamify” your SharePoint sub sites.  

Step 4. Build a detailed SharePoint Online migration plan

With your content audit and destination decided, the next step is to create a migration plan. This is your playbook that answers what, when, and how you will migrate.

Key elements of your migration plan

• What will be migrated (scope) and where it will go (mapping). Use your inventory and RMR analysis to help decide your scope. Prioritize migrations schedules in waves—such as starting with simpler departmental sites before moving to complex workloads.
• Batching and scheduling. Avoid migrating everything at once. Segment into manageable batches to reduce risk and validate progress incrementally. Set milestones, target completion dates, and measurable success checks to keep momentum.
• Cutover strategy. Decide how users will transition. A phased approach with parallel running systems is often less risky than a single big bang cutover. We recommend  phased cutovers with read-only windows and redirect guidance. Publish new URLs and change impacts well in advance.
• Tools and methods.
  
  • SPMT is a native Microsoft option that works for SharePoint content migrations.
  • Migration Manager is good for file shares but does not support SharePoint Server.
  • ShareGate provides flexibility for restructuring, metadata preservation, solution migration, and advanced reporting.
  • Whatever tool you choose, ensure it supports pre-migration reporting, incremental migrations, scheduling, automation, and detailed logging/reporting.
• Test migrations. Pilot runs are critical. Migrate a small, representative subset to validate your approach, mappings, performance, and timelines. ShareGate allows for dry runs and rollbacks to test scenarios safely. Use these pilots to refine scripts, adjust performance, and set realistic timelines.

Quick tips for test migrations

• Don’t just test during off-peak hours.
• Run concurrent migrations with multiple credentials to mitigate throttling.
• Be aware that lists with custom columns, versioning, or complex data types migrate slower.
• Local network (LAN/WAN) speed impacts performance so confirm bandwidth.
• Most timelines are underestimated, so pilots help set expectations and recalibrate timelines.
• If your destination is SPSE, you should still pilot but this will need to account for dependencies such as farm build, service app moves, DB attach/upgrade scripts, and site validation steps in the pilot plan.

Step 5. Establish your migration team, roles, and responsibilities

A successful SharePoint migration is a team effort. Assigning clear roles prevents surprises, speeds decision-making, and safeguards data integrity.

• Project manager / migration lead: Sets the timeline, tracks progress, manages risk, and bridges IT and business stakeholders.
• Migration engineers / admins: Configure the target environment, run tools, and resolve technical issues.
• Content owners / business leads: Decide what moves, validate migrated content, and participate in user acceptance testing.
• QA / test team: Verify permissions, metadata, and functionality; sign off on batches.
• Support and training leads: Deliver training and handle support before and after cutover.

Stand up a validation/escalation loop with a tracked defect log and clear SLAs for fixes and sign-offs per batch.

Where possible, delegate repeatable tasks to trained junior staff with checklists and tools to handle scaling your “lift and shift” tasks, freeing senior engineers to focus on edge cases, remediation and higher complexity work such as solutions modernization.

Don’t forget to also include security/compliance stakeholders to confirm sharing policies, retention, and legal holds in the target.

Step 6. Plan for communication and user engagement

Even the most technically perfect migration can fail if users are left in the dark. A proactive communication plan turns disruption into managed expectations.

• Tell the story early: Explain why the change matters—faster performance, Teams integration, modern UI.
• Map the journey: Share timelines, read-only windows, and cutover details well in advance.
• Empower and educate: Offer micro-training, build a champions network, host demos, and ship ‘what’s new/what’s different’ guides per audience.
• Keep support visible: Provide dedicated Teams channels or hotlines during the transition.
• Close the loop: Collect feedback, run a survey, do an issue roundup/retro and celebrate wins in a recap – then feeed lessons into the next wave or future migrations.

Tip: Document every message in a central calendar to maintain consistency and avoid confusion. Sample cadence: T-90 announce; T-30 reminder + training links; T-7 cutover details; T-0 go-live; T+7 feedback asks; T +14 next step insights/actions based on feedback.

Keep planning iterative

A migration plan isn’t static. It should evolve as test migrations uncover issues, timelines shift, and business needs change. Treat planning as a living playbook that’s continuously refined throughout the project and updated after each pilot/wave based on findings, feedback and metrics.

‍