SharePoint Migration Runbook: Discovery, Permissions Mapping, Testing, and Cutover

Overview

The safest way to migrate files and sites to SharePoint Online is to treat the project as a controlled change to information, permissions, and business processes—not as a simple transfer of folders. A technically successful copy can still create operational problems if users cannot find content, inherited permissions are misunderstood, links break, metadata is lost, or sensitive records move into the wrong location.

A SharePoint migration plan should therefore answer five questions:

1. What exists? Identify sites, libraries, file shares, personal storage, applications, owners, file types, volumes, and business dependencies.
2. What should move? Classify content as migrate, archive, remediate, retain in place, or delete according to approved policy.
3. Where should it go? Map source locations to SharePoint sites, libraries, folders, metadata, hubs, and Microsoft Teams-connected workspaces.
4. Who should access it? Rebuild access through Microsoft 365 groups, SharePoint groups, security groups, or carefully reviewed individual permissions.
5. How will success be proven? Define test cases, business-owner acceptance, reconciliation checks, security validation, and a support process before cutover.

Begin with the information architecture rather than copying the existing file-share structure unchanged. A flat folder tree may reflect years of exceptions rather than a sustainable design. Review how to plan a SharePoint information architecture that scales, then document the target structure before selecting a migration path or configuring a migration tool.

Checklist by scenario

Scenario 1: Discovery and inventory

Create an inventory that can be filtered by owner, department, sensitivity, source system, and migration wave. At minimum, record:

• Source path, site, library, or application.
• Business owner and technical contact.
• Approximate item count, file volume, and largest files.
• File types, unsupported or unusual formats, and encrypted content.
• Last modified date, usage indicators, and duplicate or obsolete content.
• Current permissions, external access, and known broken inheritance.
• Retention, legal hold, records, privacy, or regulatory considerations.
• Links, workflows, scripts, integrations, templates, and applications that depend on the source location.

Use a decision column for each location: migrate, archive, remediate first, leave in place, or delete after approval. Do not use age alone as the reason to delete content. Have the business owner confirm the decision and retain the approval with the project record.

Scenario 2: Source-to-target mapping

A mapping table turns a broad migration into a set of testable assignments. Use columns such as:

Specify whether the target is a communication site, team site, hub-associated site, document library, list, or another supported destination. Avoid creating a new site for every folder without a governance reason. Conversely, do not place unrelated departments or confidential work into one library simply to reduce the number of sites.

For content that will be discovered through search, define owners, content types, required metadata, naming conventions, and navigation. The guidance in SharePoint search best practices can help connect the migration design to findability after launch.

Scenario 3: Permissions mapping

Permissions require a separate workstream. Document the source principal, source level of access, intended target principal, target level, approval owner, and review date. Prefer role- or group-based access over large numbers of direct user assignments. Confirm whether a target Microsoft 365 group, security group, SharePoint group, or site membership model is appropriate.

Before migration, identify:

• Unique permissions at the site, library, folder, and item levels.
• Disabled accounts, departed users, nested groups, and service accounts.
• External users and sharing links that require review.
• Confidential, personal, regulated, or legally held content.
• Users who need read access but should not edit, share, or delete.

Use the project’s approved access model rather than copying every historical exception. Review external sharing controls and review steps before moving content that has guest or anonymous-style sharing dependencies.

Scenario 4: Pilot and migration waves

Choose a pilot that represents normal complexity: include common file types, realistic permissions, active users, metadata requirements, and at least one workflow or integration. A pilot made only of clean, low-risk files can create false confidence.

Run migration waves by business unit, site, content type, or dependency. For each wave, record scope, source freeze requirements, expected duration, business owner, support contacts, success criteria, and the decision maker who can pause or proceed. Validate the migration tool and supported path against current Microsoft guidance at the start of the project; capabilities, limits, and service behavior can change.

Scenario 5: Cutover and rollback planning

Before cutover, communicate what changes, when access may be restricted, where users will work, and how issues will be reported. Establish whether the final pass is incremental, whether users must stop editing the source, and how late changes will be handled.

A practical cutover sequence is:

1. Confirm approvals, scope, backups or source retention, and the change window.
2. Apply the agreed source freeze or read-only period.
3. Run the final migration pass and capture logs.
4. Reconcile counts, sizes, timestamps, versions, metadata, and errors.
5. Test permissions with representative user accounts.
6. Validate links, workflows, Teams connections, search, and key business processes.
7. Send the new location and support instructions to users.
8. Keep the source available for the approved fallback period, if policy and storage allow.

What to double-check

Migration completeness: Compare source and target item counts, total volume, failed items, skipped items, and exception reports. Investigate discrepancies rather than assuming they are harmless. Check representative folders, large files, files with long names, special characters, deep paths, version histories, and documents with coauthoring or check-out requirements.

Metadata and behavior: Confirm that required columns, content types, dates, authors, versions, and document IDs behave as expected. Test views, filters, approvals, retention labels, Power Automate flows, templates, and custom forms. A document that opens is not necessarily a document that migrated successfully if its process or classification was lost.

Permissions: Test as an owner, ordinary member, read-only user, external user where applicable, and a user who should have no access. Verify that inheritance, sharing links, group membership, and access requests match the approved design. Read document management guidance alongside your organization’s security and records requirements.

Performance and limits: Review library design, views, file sizes, storage allocation, and large-list considerations before loading a high-volume destination. The project team should confirm current service limits and migration-tool throttling guidance rather than relying on an old project estimate. See the reference on SharePoint storage and large-list performance.

User readiness: Ask users to complete task-based acceptance tests: find a document, edit it, restore or view a version, share it according to policy, locate a page or library, and complete a dependent workflow. Record failures by severity, owner, workaround, and resolution date.

Common mistakes

• Copying clutter: Moving obsolete drafts and duplicates increases cost and weakens search. Require content owners to make disposition decisions before migration.
• Reproducing broken permissions: Historical access is not automatically the correct future access. Map roles to approved groups and test negative access cases.
• Ignoring dependencies: Shortcuts, mapped drives, scripts, workflows, forms, integrations, and Teams tabs may point to the old location. Inventory and test them explicitly.
• Designing around folders only: A familiar folder tree can be useful, but metadata, views, content types, and search often provide a more durable model for shared content.
• Skipping the pilot: A full production move is a poor place to discover unsupported files, unexpected throttling, or a missing business owner.
• Declaring success at completion: Migration logs show what a tool processed; they do not prove that users can work securely. Require business acceptance and post-cutover monitoring.

For a condensed operational sequence, compare this runbook with the SharePoint migration checklist. For a tool-focused decision, use the migration tool comparison, then verify current capabilities before procurement or execution.

When to revisit

Revisit this SharePoint migration plan before every pilot and migration wave, not only at project kickoff. Refresh the inventory when departments reorganize, ownership changes, new sites appear, or new workflows are introduced. Recheck Microsoft 365 admin announcements, migration-tool documentation, service limits, security settings, and records-management requirements when the project resumes after a pause or moves into a new phase.

Schedule a post-cutover review after users have completed real work. Look at failed items, support tickets, search behavior, external sharing, permissions exceptions, storage growth, and abandoned source locations. Remove temporary access, close approved source locations, update documentation, and assign ongoing owners for sites and libraries.

The practical next step is to copy the inventory fields and mapping table into the project workspace, appoint one accountable owner for each source location, and select a representative pilot. Do not schedule the final cutover until the pilot has passed reconciliation, permissions testing, business acceptance, and a documented fallback decision.