SharePoint Migration Checklist: Pre-Migration, Cutover, and Post-Move Validation

Overview

This guide gives you a practical SharePoint migration checklist organized around three stages: pre-migration planning, cutover execution, and post-move validation. It is written for admins, architects, and technical project leads who need a repeatable framework rather than a one-off task list.

Not every migration has the same shape. A department site cleanup, a tenant-to-tenant move, and a file share to SharePoint Online migration all have different constraints. Still, the same core questions apply:

• What content is moving, and what should not move?
• Who owns each source and destination?
• How will permissions, metadata, versions, and sharing links be handled?
• Which customizations, automations, and integrations need to be rebuilt or retired?
• What defines success on day one and after stabilization?

Approach the migration as both a technical and governance project. A clean move is not only about bytes copied successfully. It is about preserving the right content, improving structure where needed, and avoiding the transfer of old risks into a new Microsoft 365 environment.

If your migration also affects information architecture, team workspace design, or app dependencies, it helps to map those decisions early against related platform choices. For example, teams often benefit from revisiting OneDrive vs SharePoint differences, best uses, and admin rules and SharePoint vs Teams for file collaboration before they start moving content into the wrong destination.

Checklist by scenario

This section breaks the work into the stages you are most likely to revisit: pre-migration, cutover, and post-move validation.

Pre-migration checklist

The goal of pre-migration is to reduce uncertainty. The better your inventory and decisions are at this stage, the fewer surprises you carry into cutover.

• Define the migration scope. List source systems, site collections, libraries, lists, file shares, user drives, workflows, forms, and integrations. Identify what is in scope now, later, or out of scope entirely.
• Assign clear owners. Every source should have a business owner and a technical owner. Avoid migrating orphaned content without a retention decision.
• Classify content before moving it. Separate active collaboration content from archives, records, duplicates, and obsolete material. Migration is a good point to delete with approval rather than copy everything.
• Document source structure. Capture folders, libraries, content types, metadata, custom columns, views, permissions inheritance breaks, and external sharing practices.
• Review destination architecture. Decide which content belongs in communication sites, team sites, Teams-connected sites, OneDrive, or dedicated records locations.
• Map metadata deliberately. Check whether old columns should be preserved, merged, renamed, or dropped. Confirm managed metadata terms and required fields in the destination.
• Assess permissions. Inventory SharePoint groups, Microsoft 365 groups, unique permissions, broken inheritance, guest access, and direct user grants. Simplify where possible before the move.
• Check compliance requirements. Identify retention labels, record status, sensitivity expectations, legal hold considerations, and audit requirements. A move that strips compliance context can create a bigger issue than a delayed move.
• Review customizations. Note classic pages, scripts, InfoPath forms, SharePoint Designer workflows, JavaScript customizations, third-party web parts, and custom APIs. Decide what can be retired, replaced, or rebuilt.
• Assess automation dependencies. Workflows tied to lists and libraries often need redesign. If you are rebuilding with modern automation, a review of Power Automate with SharePoint workflow ideas can help shape practical replacements.
• Validate development dependencies. For sites using SPFx or custom components, confirm version compatibility and packaging expectations. This is one place where an admin should review the SPFx version compatibility matrix before rollout.
• Choose the migration method. Decide whether you are using native tools, a third-party migration platform, scripted transfer, or a hybrid approach. Match the method to scale, metadata handling, reporting, and rollback needs.
• Run a pilot. Pick a representative sample, including complex permissions, version history, large libraries, and business-critical content. A pilot should expose edge cases, not avoid them.
• Measure source baselines. Capture item counts, versions, file sizes, owners, permissions patterns, and known exceptions so you can compare after the move.
• Plan naming and URL rules. Check path lengths, special characters, unsupported naming patterns, duplicate file names, and any user conventions that will cause errors.
• Prepare communications. Tell users what is moving, when content will freeze, how long sync or search may take to settle, and where to ask for help.
• Define success criteria. Success should include more than transfer completion. Include user access, metadata integrity, search discoverability, workflow readiness, and priority business scenarios.

Cutover checklist

The purpose of cutover is controlled change. Keep this phase narrow, documented, and visible.

• Confirm final scope. Freeze last-minute additions unless they are approved through a change process.
• Set and enforce content freeze rules. Users need a clear point after which source content should not be edited, uploaded, or restructured.
• Take final source snapshots or reports. Preserve a last known inventory for reconciliation and support.
• Verify admin access and tool credentials. Avoid cutover delays caused by expired accounts, missing roles, or conditional access surprises.
• Check destination readiness. Ensure sites, libraries, content types, metadata, permissions groups, sensitivity expectations, and navigation are already in place.
• Run the final migration job. Monitor throughput, failures, skipped items, throttling behavior, and retry activity.
• Log exceptions in real time. Separate transient failures from structural issues such as invalid names, unsupported customizations, or permission conflicts.
• Validate priority content immediately. Do not wait for the full project review to test executive sites, operational libraries, or high-risk records areas.
• Update links and entry points. Redirect legacy bookmarks where possible, update intranet navigation, and confirm embedded links in pages or emails that matter most.
• Re-enable or replace automations carefully. Activate workflows only after confirming lists, permissions, and triggers are stable.
• Communicate cutover completion. Tell users what is live, what is still syncing, what to avoid changing, and how to report a defect.
• Maintain rollback criteria. Even if full rollback is unlikely, define when a move is considered too unstable to proceed without intervention.

Post-move validation checklist

This is where many projects underinvest. A successful SharePoint post migration validation process should test technical integrity and real usage.

• Reconcile counts. Compare source and destination counts for files, folders, lists, items, and versions where preserved.
• Check permissions behavior. Test owner, member, visitor, guest, and restricted access scenarios. Review inherited and unique permissions on sensitive libraries. For a deeper review process, see this SharePoint permissions management checklist.
• Validate metadata. Confirm required fields, choice values, managed metadata, default values, and content type mapping.
• Open and edit sample files. Verify Office documents, PDFs, media files, and checked-out or previously locked files behave as expected.
• Test version history. Make sure preserved versions are present where they were intended to be migrated.
• Review sharing links. Check whether old links broke, redirected, or need manual replacement. This is especially important for heavily shared team content.
• Confirm search indexing. Ensure content appears in search after expected crawl and indexing delays. Test important metadata filters and search-driven pages if used.
• Test workflows and forms. Validate approvals, notifications, list item creation, Power Automate flows, and any replacement for retired legacy automation.
• Review page rendering and branding. Check modern pages, navigation, hero links, web parts, embedded content, and mobile behavior where relevant.
• Monitor sync and offline use. If users rely on OneDrive sync, validate libraries, file paths, and user experience after first sign-in.
• Confirm retention and records behavior. Test label application, disposition pathways, and record restrictions in the destination according to your governance design.
• Capture user acceptance feedback. Ask business owners to validate their top five scenarios instead of requesting vague approval.
• Close or reclassify issues. Mark defects as blockers, acceptable exceptions, deferred improvements, or user training items.
• Retire the source in phases. Move from read-only to archived to decommissioned only after approvals, compliance checks, and support stabilization are complete.

Scenario notes to adapt the checklist

A reusable checklist is most useful when you adjust it for the type of move:

• File share to SharePoint Online: Focus heavily on metadata design, over-foldering, duplicate content, and user retraining.
• Classic SharePoint to modern SharePoint Online: Pay extra attention to page rebuilds, custom scripts, legacy workflows, and list form replacements.
• Tenant-to-tenant migration: Plan for identity mapping, guest access changes, sharing links, and compliance policy differences between tenants.
• Departmental intranet migration: Validate navigation, homepage governance, audience targeting assumptions, and communication plan timing. Teams redesigning the destination may also want to review SharePoint intranet examples and Viva Connections vs SharePoint intranet.

What to double-check

These are the items that commonly appear complete on paper but deserve one more pass before you declare success.

• Permissions simplification did not remove needed access. Cleanup is good, but overcorrection can disrupt business operations. Test actual personas, not just admin views.
• Migration reports match business reality. A tool may report success while users still cannot find content, open documents, or use filtered views correctly.
• Metadata defaults are not silently changing records. Default values at the library level can unintentionally rewrite classification logic.
• Automations are pointed at the new URLs and lists. Even a small rename can break triggers, approvals, or notifications.
• Custom integrations still authenticate properly. If you have apps using SharePoint APIs, confirm endpoints, scopes, and app registrations. This is a good point to revisit SharePoint REST API vs Microsoft Graph if part of the migration includes modernization.
• Library settings reflect new governance rules. Versioning, checkout, sharing, sync suitability, and external access should match current policy, not source history.
• Provisioning standards are applied consistently. If you are creating many destination sites during the migration, review your build method using SharePoint site provisioning options compared.
• Support teams have a defect triage path. Users need to know whether an issue is a permission problem, missing content, training gap, or indexing delay.

One more practical rule: validate with a business process, not just a technical control. For example, do not only check that a policy library exists. Ask whether a policy owner can upload a document, apply the right metadata, share it with the intended audience, and have it found in search.

Common mistakes

This section highlights the patterns that repeatedly weaken otherwise well-planned Microsoft 365 migration projects.

• Moving everything because cleanup feels risky. Deferred cleanup usually becomes permanent clutter in the destination.
• Treating permissions as a copy problem instead of a governance problem. If source permissions are already messy, copying them faithfully just preserves the mess.
• Ignoring user behavior. Teams may continue storing files in email attachments, desktop folders, or the wrong workspace if training is not aligned with the new design.
• Recreating outdated customizations without challenge. Migration is often the best moment to retire fragile legacy assets rather than rebuild them.
• Assuming search and sync are instant. Users often interpret normal settling time as content loss unless expectations are set clearly.
• Approving the move based only on file counts. Counts matter, but they are not enough for pages, metadata, permissions, workflow behavior, or records controls.
• Skipping a realistic pilot. A pilot that excludes your hardest libraries teaches very little.
• Letting cutover become a moving target. Last-minute scope changes create confusion and weaken accountability.
• Forgetting downstream references. Links in Teams tabs, knowledge bases, intranet pages, forms, or automation steps often break after content moves.
• Retiring the source too early. Keep a controlled read-only period until owners confirm that validation is complete.

A calm migration cadence usually beats a rushed one. That does not mean moving slowly for its own sake. It means sequencing work so that governance, communication, and technical execution support each other.

When to revisit

This checklist should be treated as a living control document, not a one-time article to skim and forget. Revisit it whenever your migration inputs change.

• Before annual or seasonal planning cycles. Budget timing, business freezes, and project windows often change cutover assumptions.
• When your toolset changes. New migration features, reporting options, or automation capabilities may reduce manual work or change your validation plan.
• When governance rules are updated. Adjust the checklist if retention, sharing, records, or sensitivity requirements change.
• When you move to a new scenario. A checklist that worked for departmental libraries may not be enough for intranets, regulated content, or tenant consolidations.
• After each pilot or wave. Add the failure patterns, naming issues, support themes, and user questions you actually encountered.
• When Microsoft 365 behavior changes in ways that affect rollout. Operational teams should keep an eye on ongoing platform changes through resources such as SharePoint Online release notes.

For your next migration wave, make this practical:

1. Copy this checklist into your project workspace.
2. Add owners and dates beside each item.
3. Mark which items are mandatory, optional, or not applicable.
4. Define five business-critical validation scenarios before cutover starts.
5. Require sign-off from both technical and business owners after post-move review.

If you do that consistently, your migration process becomes easier to repeat, easier to audit, and much easier to improve over time. That is the real value of a good migration cutover checklist: not just helping one move finish, but helping the next move start from a better place.