SharePoint Online Migration Step-by-Step Guide

SharePoint Online migration is the process of moving sites, document libraries, lists, pages, metadata, permissions, and business content into SharePoint Online. The source might be SharePoint Server, another Microsoft 365 tenant, file shares, Google Drive, Box, Dropbox, or another document management platform.

A successful migration is not just copying files. It is about moving the right content into the right structure, preserving useful metadata, fixing permissions, reducing disruption, and helping users work confidently after go-live.

This guide is written for Microsoft 365 administrators, SharePoint consultants, IT teams, and business owners planning a migration in any region, including the USA, Canada, Australia, the UK, India, and global Microsoft 365 environments. The steps are practical and apply to most SharePoint Online migration projects.

If you are new to migration planning, also read What Is Microsoft 365 Migration? and the Microsoft 365 Migration Checklist for Beginners.

What is SharePoint Online migration?

SharePoint Online migration means moving collaboration content into SharePoint Online so teams can store, manage, search, share, and protect documents in Microsoft 365. The migration can include:

• Team sites and communication sites
• Document libraries and folders
• Files, versions, and metadata
• SharePoint lists and list views
• Pages, navigation, and site content
• Permissions, groups, owners, and sharing settings
• Content connected to Microsoft Teams

SharePoint migration is usually more complex than a simple file copy because SharePoint is not only storage. It includes structure, security, metadata, search, collaboration, and governance.

Step 1: Define the migration scope

Start by deciding exactly what is moving. Do not assume every site, folder, list, or old file should move. A clear scope reduces cost, migration time, and user confusion.

• In scope: active business sites, important document libraries, current project content, required list data, and approved archives.
• Out of scope: duplicate sites, abandoned project areas, personal clutter, old test sites, unsupported files, and content that should be archived separately.
• Later phase: complex customizations, legacy workflows, classic pages, or low-priority archives that need more review.

Write the scope in plain language and get agreement from business owners before you choose tools or dates.

Step 2: Inventory SharePoint sites and content

Inventory is the foundation of the migration. Without inventory, you cannot estimate timeline, risk, storage, tool limits, or support needs.

Capture these details for each site:

• Site URL, title, template, owner, department, and business purpose
• Total storage, file count, folder depth, large files, and old content
• Document libraries, lists, pages, views, and metadata columns
• Unique permissions, broken inheritance, external sharing, and guest access
• Classic pages, custom scripts, workflows, InfoPath forms, or custom solutions
• Business-critical content, compliance requirements, and retention needs

This inventory helps you separate simple migrations from sites that need redesign, cleanup, or special handling.

Step 3: Clean up before migration

Migration is the best time to remove clutter. Moving everything as-is may look faster, but it often creates a messy SharePoint Online environment that users do not trust.

• Archive or delete obsolete content based on business and retention rules.
• Remove duplicate folders and old working copies.
• Fix unsupported file names, blocked file types, and very long paths.
• Identify libraries with too many folders and consider metadata-based views.
• Remove stale owners, inactive users, and unused external sharing links.

Good cleanup improves migration performance and creates a better user experience after go-live.

Step 4: Design the target SharePoint Online structure

Do not simply recreate an old file server or old SharePoint farm inside SharePoint Online. Design the target around business ownership, collaboration, security, and search.

Site structure

Use separate sites when content has different ownership, lifecycle, security, or business purpose. Examples include HR, Finance, Projects, Policies, Sales, Operations, and department workspaces.

Document libraries

Use document libraries to organize content by business process, not just by old folder names. For example, one HR site might have libraries for Policies, Employee Documents, Templates, and Benefits.

Metadata and views

Use metadata when users need to filter, group, or find documents across many categories. Metadata is especially useful for policies, contracts, projects, records, templates, and controlled documents.

For more SharePoint fundamentals, see SharePoint Online Document Library Explained.

Step 5: Plan permissions carefully

Permissions are one of the biggest SharePoint migration risks. Content can migrate successfully but still fail the business if the wrong people can access it or the right people cannot.

Before migration, answer these questions:

• Who owns each site after migration?
• Which users need read, edit, or owner access?
• Which permissions should be simplified?
• Where does broken inheritance exist?
• Which external users or guests still need access?
• Should access be managed with Microsoft 365 groups, security groups, or SharePoint groups?

As a rule, keep permissions simple. Site-level or library-level access is easier to manage than many unique folder and item permissions.

Step 6: Choose the right migration tool

The right SharePoint migration tool depends on the source, size, permissions, metadata, versions, timeline, reporting needs, and complexity. Common options include Microsoft native migration tools and third-party tools for advanced migration scenarios.

Evaluate tools based on:

• Supported source and target platforms
• Metadata and version history support
• Permission mapping and group mapping
• Incremental migration and delta sync options
• Error reporting and retry behavior
• Handling of large files, long paths, special characters, and throttling
• Support for lists, pages, Teams-connected sites, and custom content

Do not choose a tool before the assessment. Choose the tool after you know what must move and how much fidelity the business needs.

Step 7: Prepare the SharePoint Online destination

The destination must be ready before the first migration wave. If target sites, groups, naming, retention, or sharing settings are not prepared, the migration can create confusion or security gaps.

• Create target sites and confirm site owners.
• Create required document libraries, columns, content types, and views.
• Set sharing policies, guest access, retention, sensitivity, and DLP requirements.
• Confirm storage, licenses, user accounts, and group membership.
• Prepare navigation, hub site association, and landing pages if needed.
• Document naming standards for sites, libraries, and groups.

Step 8: Run a pilot migration

A pilot migration tests the plan before users depend on it. Choose a small but realistic site or library. Avoid using only a tiny test folder because it may not expose real issues.

During the pilot, validate:

• Files and folders moved correctly
• Metadata and columns are preserved or mapped correctly
• Version history moved if required
• Permissions work for owners, members, visitors, and guests
• Links, pages, list views, and navigation are usable
• Users understand where to find migrated content

Fix the process after the pilot. Do not scale a broken migration pattern.

Step 9: Migrate in waves

Large SharePoint migrations should be planned in waves. Waves reduce business disruption and make support easier.

Common wave planning options:

• By department: HR, Finance, Sales, Operations, IT.
• By business priority: low-risk sites first, critical sites later.
• By complexity: simple document libraries first, complex sites after pilot fixes.
• By location or time zone: useful for global organizations with users in the USA, Canada, Australia, Europe, and Asia-Pacific.

For each wave, track start time, completion time, migrated size, error count, owner sign-off, and open issues.

Step 10: Validate after each migration wave

Validation should not rely only on a migration tool summary. Tool reports are useful, but business validation confirms whether users can work.

Check these items after each wave:

• Item counts, file counts, folder counts, and storage size
• File access for owners, members, visitors, and external users
• Metadata, required columns, views, and content types
• Version history and modified dates where required
• Links, pages, navigation, web parts, and list views
• Search results, OneDrive sync, Teams file access, and sharing behavior
• Retention, sensitivity labels, DLP, and compliance settings

Get business owner sign-off before you mark a site as complete.

Step 11: Communicate with users

SharePoint migrations affect daily work. Users need clear communication before, during, and after migration.

• Explain what is moving and when.
• Tell users whether the source will become read-only.
• Share the new SharePoint Online site links.
• Explain any changes to folder structure, metadata, permissions, or sharing.
• Provide support contacts and known issue guidance.
• Give short training on document libraries, search, sharing, sync, and version history.

Good communication reduces tickets and improves adoption.

Step 12: Set governance after migration

Governance keeps the migrated environment healthy. Without governance, SharePoint Online can become messy again.

• Define site owner responsibilities.
• Review external sharing and guest access regularly.
• Use naming standards for sites, Teams, libraries, and groups.
• Review inactive sites and old project areas.
• Apply retention and sensitivity policies where required.
• Document how users request new SharePoint sites or Teams.

Common SharePoint migration mistakes

• Moving everything: old clutter becomes cloud clutter.
• No site owners: IT cannot validate every business document alone.
• Ignoring permissions: broken access creates security and support issues.
• Rebuilding file shares exactly: SharePoint works better with sites, libraries, metadata, and views.
• No pilot: production users discover problems first.
• No communication: users do not know where content moved.
• No post-migration governance: the new environment becomes hard to manage.

SharePoint Online migration checklist

• Migration scope approved
• Site and library inventory completed
• Business owners assigned
• Source content cleaned up
• Target site structure designed
• Permissions reviewed and mapped
• Migration tool selected
• Destination sites and libraries prepared
• Pilot migration completed
• Production waves scheduled
• User communication prepared
• Validation checklist approved
• Support plan ready
• Governance plan documented

The bottom line

A SharePoint Online migration works best when it is planned as a content, permissions, and adoption project. Start with inventory, clean up what you can, design the target structure, run a pilot, migrate in waves, validate carefully, and support users after go-live.

Do not just move SharePoint content. Improve the way people find, protect, and use it in Microsoft 365.

---