The most powerful SharePoint migration tool for IT admins

ShareGate Migrate handles SharePoint-to-SharePoint migrations across on-premises and Microsoft 365. That means on-prem to online, on-prem to on-prem, tenant-to-tenant, and even restructuring within the same tenant.

Beyond SharePoint sites, you can also migrate OneDrive, Teams, and file shares into Microsoft 365. Need to move from Google Drive (including Shared Drives) or Box? We've got that covered too.

ShareGate Migrate handles all the SharePoint essentials: sites, lists, libraries, files, folders, metadata, content types, permissions, and versions. We copy everything as-is, so what you had in the source is what you get at the destination.

What we don't migrate: third-party add-ons, custom code, or apps built outside SharePoint. Classic pages and web parts will move, but they won't automatically modernize. If you need those to work in a modern site, you'll need to rebuild them.

Yes. ShareGate Migrate doesn't cap how much you can move, but SharePoint and Microsoft 365 do care about how you move it.

Don't run millions of items as one giant job. Break migrations into manageable batches, typically 500k to 800k items per operation, with 1M as a practical ceiling. This avoids throttling and keeps things moving smoothly. Need to go faster? Run multiple migrations in parallel across different machines.

Check ShareGate Migrate's migration report. Every item gets a status: Success, Warning, Error, or Skipped. A migration is successful when ShareGate sends the content and SharePoint confirms the import.

Don't just count files at the destination—ShareGate tracks versions, folders, and other objects too, so the numbers won't match a simple file count. For extra confidence, run Source Analysis before and after your migration, then compare the totals.

Yes, if you run a migration with "Copy and replace" mode. ShareGate will overwrite whatever's at the destination, even if users updated it after your initial migration.

To avoid overwriting user changes, use "Don't copy existing items" or "Copy if newer (incremental)." Incremental mode only replaces destination items when the source version is newer based on last modified date.

Yes to all three. Permissions are preserved at the item level - including broken inheritance and unique permission scopes - as long as the destination users exist and are mapped. Metadata columns (including managed metadata and content types) come over intact. Version history migrates too, but count each version as a separate item when estimating batch sizes: a document with 10 versions counts as 10 objects, not one. For very large libraries, running a Source Analysis report beforehand tells youexactly how many versioned objects you're dealing with before you commit to a batch size.

Classic pages and web parts migrate, but they won't automatically modernize. If you're moving classic ASPX pages with custom views or forms, those transfer as-is to the destination. One thing to know: Microsoft has been deprecating legacy APIs used for classic page migration - if you're seeing errors on classic content, it's almost always a Microsoft-side API issue, not ShareGate. If you're inheriting a large classic environment, now is a good time to consider rebuilding those pages in modern format before migration, rather than carrying technical debt into the new tenant.

Throttling comes from Microsoft, not ShareGate. When you're migrating, a single file can trigger many API calls - multiply that across millions of items and the volume gets Microsoft's attention. The most effective ways to reduce throttling: aim for 500k–800k items per operation as a practical ceiling, with 1M as the absolute limit (items means files, folders, and versions combined - a file with 10 versions is 10 items); enable Insane Mode and grant consent to the ShareGate Azure enterprise app, which gives the migration an app identity rather than a user identity, which Microsoft throttles less aggressively; and split workloads across multiple machines rather than running everything through one. Running parallel streams on separate machines consistently outperforms one large concurrent job from a single machine.

Yes. ShareGate handles on-prem SharePoint to SharePoint Online migrations, including classic on-prem farms to Microsoft 365 tenants. The same tool covers on-prem to online, on-prem to on-prem, and tenant-to-tenant scenarios. One thing to keep in mind: custom code, third-party add-ons, and apps built outside SharePoint won't migrate - those need to be rebuilt for the modern environment. Classic web parts do move, but you'll want to plan for modernization if the destination is running in modern mode.

ShareGate now supports sensitivity label migration for SharePoint, OneDrive, and Teams. If your source and destination tenants both have sensitivity labels configured, you can map source labels to their destination equivalents before the migration runs - similar to how user mapping works. Labels with the same name get matched automatically; you review and adjust any that don't align. Content labels and structural labels (applied at site or library level) are handled separately in the copy options. If the destination tenant doesn't have equivalent labels configured, you'll need to set them up there first before the migration runs.