SharePoint Server to SharePoint Online

Why move to SharePoint Online now?

The deadline already passed. SharePoint Server 2016 and SharePoint Server 2019 both reached end of life on 14 July 2026, which was nearly three months ago.

Running past that date means no security updates and no support calls, which is why SharePoint Online stopped being a project and became a deadline. SharePoint Server 2013 went the same way back in April 2023, and 2010 long before it. Only SharePoint Server Subscription Edition is still supported, and it follows the Modern Lifecycle Policy with at least twelve months of notice before anything changes. Once the content is in the cloud, a later tenant move is a different job again, covered in how to migrate a SharePoint site to another tenant.

So the honest position is this. If you are still on a 2016 or 2019 farm, the question stopped being whether to move to SharePoint Online and became how fast you can do it without breaking things.

Which server versions migrate to SharePoint Online?

End of life does not lock your content in, and nothing stops a 2010 farm reaching SharePoint Online today. Microsoft's SharePoint Migration Tool reads older farms happily, and the supported source list is wider than most people assume.

• SharePoint Server 2010, 2013, 2016 and 2019. All four are supported sources into SharePoint Online.
• SharePoint Foundation 2010 and 2013. Supported as well.
• Local and network file shares. Treated as a first class source, which matters when half your content never made it into SharePoint.

Destinations are SharePoint Online, OneDrive and Teams inside Microsoft 365. Authentication covers NTLM, Kerberos, Forms, ADFS, SAML based claims, multifactor and client certificates, so an old farm with an unusual sign in setup is rarely a blocker.

One gap is worth naming early. The tool cannot read SharePoint Online as a source, so it does nothing for a tenant to tenant move. The full list of what it does and does not handle sits in SharePoint Migration Tool limitations.

What do you check before the first batch?

Scan the farm and read the risk codes before a single item reaches SharePoint Online. This is the step that decides whether your project is a transfer or a rebuild, and it is free.

SharePoint Migration Assessment Tool reached end of support on 1 October 2026 and had already stopped working in June 2023, so the scan built into the migration tool is now the Microsoft route. Run it on its own, before you create any migration task.

• Blockers first. A list above 30 million items fails outright. Unique permissions above 50,000 per library need flattening before anything moves.
• Warnings that bite later. Above 20,000 items a list exceeds the index creation limit, so search comes out incomplete while the job reports success.
• Unsupported codes. Custom solutions, custom content types, custom workflows and most custom pages all surface here with their own codes.
• Path length. SharePoint Online caps the full decoded path at 400 characters, and deep farm structures breach it constantly.

Count the unsupported codes rather than the gigabytes. That number, not your storage figure, tells you how long the project runs and what it costs, as SharePoint migration cost sets out line by line.

What are the SharePoint Online migration steps?

Run them in this order. Steps three and four are the ones teams skip when a deadline is behind them, and they are the ones that cause the re-runs.

1. Inventory the farm. Sites, lists, libraries, item counts, average file size, workflows, forms and custom solutions. Numbers before dates.
2. Scan and read the codes. Fix blockers, shorten long paths at source and flatten permission scopes while the content is still on your own hardware.
3. Clean up before you move. Sites nobody opened in a year cost the same to migrate as live ones. Archive them instead.
4. Build the destination. Site architecture agreed, licences assigned, identities synced to Microsoft Entra ID so permissions have somewhere to land. The wider sequence is in the Microsoft 365 migration planning checklist.
5. Pilot one real site. Average size, real permissions, real users. Time it and record items per minute.
6. Migrate in waves, off peak. Evenings and weekends, because Microsoft throttles background apps harder during weekday daytime hours. The published limits are in SharePoint migration throttling.
7. Run an incremental pass. Save the task and rerun it, so only new or updated files move on the day.
8. Verify, then decommission. Prove what landed before the old farm is switched off, not after.

Our RecoveryTools SharePoint Migrator covers the routes Microsoft's free tool does not, including site to site between tenants once you are on SharePoint Online. A readable copy on your own storage during the move comes from the SharePoint Backup Tool.

When do you need the PowerShell route?

Most farms reach SharePoint Online without it. The wizard handles the ordinary cases, and PowerShell earns its place when you want packages built, converted and submitted under your own control.

The flow runs through four cmdlets. New-SPOMigrationPackage builds a package from the source, ConvertTo-SPOMigrationTargetedPackage retargets it at the destination web and library, then Invoke-SPOMigrationEncryptUploadSubmit encrypts and submits it. Teams using their own Azure storage swap the last one for Set-SPOMigrationPackageAzureSource and Submit-SPOMigrationJob, which can attract Azure bandwidth charges.

Microsoft publishes the sizing rules for this path, and they are worth following rather than discovering.

• Package size 10 to 20 GB. Split anything larger with the parallel import switch.
• File size 2 GB on this route. Lower than the 250 GB the migration API allows elsewhere.
• Keep the target site closed. Microsoft asks you to keep it inaccessible to users until the job completes.
• Jobs run first come, first served. Expect a short delay even when the queue is empty.

You also need to be a site collection administrator on the target, and the SharePoint Online Management Shell installed with every earlier version removed first.

What reaches SharePoint Online and what gets rebuilt?

Content reaches SharePoint Online. Configuration mostly does not, and sorting the two in week one prevents the arguments later.

Swipe the table sideways to see every column.

Two details catch people out. Deny permissions are not saved at all, and inherited permissions are not copied, only unique ones. The detail sits in how to migrate SharePoint permissions to another tenant, and version behaviour at the far end is covered in SharePoint version history migration. The metadata switch is off by default and needs the target taxonomy built first, which is set out in how to migrate SharePoint document libraries with metadata.

Should you run hybrid during the move?

Hybrid keeps the farm and SharePoint Online running side by side while content moves across gradually. It suits large estates and it costs something real, so decide deliberately.

It buys you a staged move with no hard cutover weekend, and users keep working on whichever side holds their content. It costs you a farm you are still patching, two places to search and a longer window where people ask which address to use.

With 2016 and 2019 already out of support, hybrid now means running unsupported infrastructure for longer. That tilts the answer toward short waves and a definite end date rather than an open ended parallel run.

How do you verify the migration landed?

A finished job and a complete site in SharePoint Online are different claims. Check the second one before the farm is turned off.

• Item counts per library. Compare site by site rather than as one total, because one failed library hides inside a big number.
• Sign in as real users. Three ordinary staff across three sites, plus one account that should no longer have access.
• Open a deep version history. Count the versions on a file you know well, then check again two weeks later.
• Search the report for long paths. Items over 400 characters fail quietly and nobody notices until someone looks for them.
• Test one converted workflow. A Designer workflow that became a Power Automate flow needs a real run, not a green tick.

Timing the entire programme is its own calculation, and the published throughput figures behind it are in how long does a SharePoint migration take. Teams without spare hands for the verification pass hand it to our cloud migration service.

Frequently asked questions

Where to start this week

Run the scan. Not the migration to SharePoint Online, the scan, and read the risk codes rather than the totals.

That report splits your farm into two lists. Content that moves to SharePoint Online on its own, and customisations somebody has to rebuild. The first list is a schedule. The second is a project, and it is the one that decides your real end date.

With 2016 and 2019 already past end of life, the useful question is no longer when to start. It is which of those two lists you are still pretending is short, because only one of them moves to SharePoint Online on its own.

Published 9 October 2026. Supported sources, cmdlets and package limits come from what is supported by SPMT, upload on premises content using PowerShell and SPMT scan risk codes.