Migrating to SharePoint Online: A Step-by-Step Guide
Microsoft has ended support for SharePoint Server 2010 (2021), SharePoint Server 2013 (2023), and SharePoint Server 2016 and 2019 (July 2026). That means no more security fixes for those versions. If you still run one of them, moving to SharePoint Online (part of Microsoft 365) is now a risk and cost decision, not just an upgrade.
This guide is for IT managers and admins moving from on-premise SharePoint to SharePoint Online. It covers what a migration involves, how to plan it, which tools to use, and the exact steps to follow.
Moving from one Microsoft 365 tenant to another, or from a file server or Box to SharePoint? The core ideas are the same, but the tools and steps differ. This guide focuses on SharePoint Server to SharePoint Online.
Understanding the SharePoint Online Migration Process
What a migration really is :
A migration is not just copying files. You are moving content, sites, permissions, metadata, and version history from your own servers to Microsoft’s cloud. Some things move easily. Others must be rebuilt.
Why companies move
- Support and security: old versions no longer get patches
- Lower upkeep: no servers, patching, or hardware refresh to manage
- Work from anywhere: users reach files from any device
- Better connection to other tools: Teams, OneDrive, Power Automate, and Copilot
- Automatic updates: Microsoft handles upgrades
What moves easily and what does not
Usually moves well:
- Document libraries and lists
- Sites and subsites
- Permissions and metadata
- Version history
Needs extra work:
- Custom farm solutions (not supported online)
- SharePoint 2010 and 2013 workflows (rebuild in Power Automate)
- InfoPath forms (rebuild in Power Apps)
- Custom web parts and heavy page customizations
- Custom search settings
Common risks
- Broken links after the move
- Lost or changed metadata
- Wrong permissions (people see what they should not, or cannot see what they need)
- File paths over 400 characters, and files over 250 GB, which SharePoint Online will not accept
- Slow transfers because Microsoft limits (throttles) heavy usage
- Users who are confused on day one
Creating a Robust Migration Strategy
Most failed migrations fail in planning, not in the tool. Spend real time here.
Step 1: Take inventory
List every site, its size, its owner, when it was last used, and what customizations it has. Use an assessment tool (for example, Microsoft’s SharePoint Migration Assessment Tool or the scan in ShareGate) to find problems early.
Step 2: Decide what to move
Sort every site into one of three groups:
- Keep: move it
- Archive: store it cheaply, outside SharePoint
- Delete: nobody uses it
A lot of old content is never opened. Moving it only adds cost and time.
Step 3: Pick your approach
| Approach | How it works | Best for |
|---|---|---|
| Big bang | Move everything in one cut-over window | Small environments |
| Phased (waves) | Move groups of sites over weeks or months | Most companies |
| Hybrid | Keep some content on-premise, some online | Strict data rules or complex apps |
Phased migration is the safest choice for most teams. You learn from each wave.
Step 4: Design the target structure
Do not copy your old mess into the cloud. Decide how sites will be organized (hub sites, Teams-connected sites, department sites) and simplify permissions before you move them.
Step 5: Plan for people
- Name an owner for each site
- Tell users what is changing and when
- Plan training and a support channel for the first two weeks
- Write a rollback plan in case a wave fails
Choosing the Right Migration Tools
There is no single best tool. The right one depends on your source, your data size, and your budget.
| Tool | Best for | Cost |
|---|---|---|
| SharePoint Migration Tool (SPMT) | Small to medium moves from SharePoint Server and file shares | Free from Microsoft |
| Migration Manager (SharePoint admin center) | Large file share moves and cloud sources such as Box, Dropbox, and Google Drive | Included with Microsoft 365 |
| ShareGate | Moves that need permissions, metadata, and clear reports | Paid |
| AvePoint Fly or Quest Metalogix | Large or complex enterprise migrations | Paid |
How to choose
- What is your source? SharePoint 2013, 2016, 2019, a file server, or another cloud?
- How much data? Hundreds of GB or many TB?
- Do you need to keep permissions and metadata exactly? Free tools handle the basics. Paid tools handle edge cases better.
- Do you need reports for audits or managers?
- How much support do you need?
Tip: Test two tools on the same small site before you decide. Compare speed, errors, and how well permissions were kept.
Executing the SharePoint Online Migration Process Step-by-Step
The steps
- Prepare your Microsoft 365 tenant. Check licenses, admin roles, and your domain. Make sure users exist in Microsoft Entra ID (usually synced with Microsoft Entra Connect) so permissions can match the right people.
- Clean the source. Fix file paths over 400 characters, remove invalid characters in file names, deal with files that are too large, and check in any checked-out files.
- Create the destination sites. Build the structure you designed before you move any content.
- Map users and permissions. Match old accounts to new ones. Wrong mapping is one of the most common causes of permission errors.
- Run a pilot. Move one small, low-risk site. Check content, permissions, metadata, and links with real users.
- Migrate in waves. Run large transfers outside work hours and watch for throttling.
- Run incremental passes. These copy only the changes made since the last run, so the final cut-over is short.
- Validate. Compare item counts, spot-check permissions and version history, and test important links.
- Rebuild what cannot move. Recreate old workflows in Power Automate, InfoPath forms in Power Apps, and custom code with the SharePoint Framework (SPFx).
- Cut over. Set the old site to read-only, run a final incremental pass, update links and shortcuts, and tell users.
- Support and clean up. Watch for problems for the first weeks. Keep the old servers (read-only) for an agreed period before you shut them down.
Quick migration checklist
- Inventory of all sites completed
- Keep, archive, and delete decisions made
- Target structure approved
- Microsoft 365 tenant and user sync ready
- Tool chosen and tested on a pilot
- Long paths and invalid file names fixed
- Custom solutions and workflows listed for rebuild
- Communication and training plan ready
- Rollback plan written
- Validation steps agreed with site owners
Mistakes to avoid
- Moving everything without cleaning first
- Skipping the pilot
- Forgetting user mapping, so permissions break
- Ignoring workflows and custom code until the last week
- Switching off the old servers on cut-over day
- Giving users no training
How long does it take?
As a rough guide, a small migration with a few sites and under 500 GB can take two to four weeks including testing. Large migrations with custom solutions often take three to six months. Planning and rebuilding custom parts usually take longer than the file transfer itself.
Final thought
A good migration is mostly preparation. Clean your content, choose the tool that fits your situation, test with a pilot, and move in waves. If your environment has heavy customizations or very large data, bringing in an experienced SharePoint migration team early can save weeks of rework.
You may also like : AI Can Build SPFx Solutions, But Can We Trust It to Upgrade Them?
What’s the Real ROI of SharePoint Syntex for Your Organisation?
Get a practical ROI calculator + implementation checklist used by enterprises to modernize SharePoint with AI, without trial-and-error.
