SharePoint Migration Tool Limitations

What does SharePoint Migration Tool migrate from?

Week one of a migration project is where most SPMT limitations get discovered, and almost all of them come down to one sentence. SharePoint Migration Tool reads on premises content.

Microsoft supports four server versions as a source: SharePoint Server 2010, 2013, 2016 and 2019. SharePoint Foundation 2010 and 2013 work too. Local file shares and network file shares round out the list. Content lands in SharePoint, OneDrive or Teams inside Microsoft 365.

Read that list again and notice what is missing. SharePoint Online is not on it. Microsoft's own FAQ states the tool cannot migrate from SharePoint Online, and cannot move content from one Microsoft 365 tenant to another.

If two tenants are involved, this tool was never the answer. That route needs Microsoft's cross tenant service or a third party tool, and the choice between them is covered in how to migrate a SharePoint site to another tenant.

Which SPMT limitations are hard numbers?

The useful SPMT limitations are the ones you can measure before you start. Microsoft publishes them, and a scan reports every item that breaks one.

Three of those eight are silent. A warning scrolls past in a CSV report, the job says finished and somebody finds the gap in March. Counting first is cheaper than explaining later, which is why the first job in any plan is discovery rather than transfer.

What does SharePoint Migration Tool leave behind?

Numbers are the easy half. The harder SPMT limitations are the things that simply do not come across, and Microsoft names them in its scan risk codes.

• InfoPath forms. Not supported. Every form rebuilds by hand or moves to Power Apps.
• Master pages. Excluded from site and site collection migrations, so branding goes with them.
• Custom New, Edit and View forms. Content arrives. The forms around it do not.
• Custom content types. Reported as UNKNOWN_CONTENT_TYPE and dropped.
• Custom solutions and features. CUSTOM_SOLUTION_UNSUPPORTED and FEATURE_UNSUPPORTED cover anything a developer added.
• Hidden taxonomy lists and style libraries. Flagged as unsupported list templates.
• Custom pages. Wiki pages and web part pages survive. Anything else raises PAGE_UNSUPPORTED.

Two more rules surprise people. You cannot migrate a site structure without its content, and you cannot choose the destination site template. SharePoint Migration Tool decides the template from what it sees at both ends. Site Pages are stranger still, because they move only through a CSV or JSON upload rather than the interface.

Which web parts does SPMT drop?

Microsoft maintains a page listing every web part SharePoint Migration Tool supports, and the unsupported column is longer than teams expect. Entire groups go.

• Business Data. Every one of them, including Excel Web Access, Visio Web Access and KPI indicators.
• PerformancePoint. All of them.
• Search and Search-Driven Content. Content Search goes, and so do all eight Search-Driven parts.
• Forms. HTML Form and InfoPath Form, plus List Form.
• Media and Content. Media and Promoted Links.
• Document sets. Document set contents, document set properties and Find By Document ID.
• Odds and ends. Outlook Web Access, SQL Server Reporting Services Report Viewer, Chart Viewer, WSRP viewer, Tag cloud, Followed Counts, Shared With Me View, Web analytics.

One trap sits underneath all of it. Several unsupported web parts need the Allow custom script setting switched on in the destination tenant, and Microsoft asks for at least 24 hours between flipping that setting and starting the migration. Teams who find this out on a Saturday lose the weekend.

What happens to permissions during migration?

Permissions migrate from file shares and from SharePoint on premises, so the short answer is yes. Volume is the catch.

A library cannot hold more than 50,000 unique security scopes. Microsoft recommends staying under 5,000 before a migration, because every scope above the list view threshold adds database round trips that slow the transfer down. Broken inheritance builds scopes faster than anyone expects: one folder shared with one person creates one more.

So the work is not a setting inside SharePoint Migration Tool. It is a cleanup at source. Replace per item sharing with group membership, let inheritance do the job again and the count falls on its own.

Mapping identities is the other half, and it belongs in the plan rather than the migration window. The sequence for that sits in our Microsoft 365 migration planning checklist.

Do workflows survive SharePoint Migration Tool?

Partly. The split is worth knowing before you promise anything. Out of the box 2010 workflows migrate. SharePoint Designer 2010 and 2013 workflows migrate too, and version 4.1 sends them to Power Automate rather than recreating them in place.

Custom workflows do not migrate. The scan returns WORKFLOW_UNSUPPORTED and the job carries on without them. Run history goes nowhere either, so approval records and audit trails stay on the old farm.

For anything with a compliance requirement attached, keep the source farm readable until the new process has produced its own records.

Does SPMT run incremental passes?

Yes, and plenty of articles get this wrong. A saved task reruns and moves only files that are new or updated since the last run, which is exactly the shape a safe cutover needs. Long batch during the week, short pass on the day.

One behavior catches people out. On an incremental run, web parts are replaced by default. If somebody has been rebuilding pages at the destination between passes, that work gets overwritten unless the setting is switched to leave them alone.

Taxonomy behaves similarly. Managed metadata migration is off by default and refreshes on later rounds once enabled, so turning it on halfway through a project gives inconsistent results across batches.

How do you scan a site now that SMAT is gone?

SharePoint Migration Assessment Tool reached end of support on 1 October 2026, four days before this went up. It had already stopped working after 30 June 2023 when the Azure AD Graph service retired. Microsoft now points to the scan built into SharePoint Migration Tool.

1. Install the current build. Version 4.1.130.4 shipped in August 2026 and carries certificate based authentication plus the Entra option for custom Azure storage.
2. Run the scan on its own first. Scan before you create a migration task, so the report arrives before anybody promises a date.
3. Read the risk codes, never the totals. A green summary with 400 unsupported content types underneath it is not a green project.
4. Fix blockers ahead of warnings. ITEM_COUNT_EXCEED_LIMIT fails the migration. UNIQUE_PERMISSION_EXCEED_LIMIT needs permissions flattened before anything moves.
5. Shorten paths at source. Renaming a nested folder fixes hundreds of items at once, and it is far quicker than fixing them one by one later.
6. Scan again and compare. Two clean scans in a row, and the window is safe to book.

Everything in that list is free. The expensive version of this work is doing it after a failed weekend.

Where do SPMT limitations stop a project?

Three situations put SharePoint Migration Tool out of reach, and every one needs a different answer.

Two tenants. A merger, a divestment or a rebrand means SharePoint Online on both ends. SPMT cannot read that source at all. Our RecoveryTools SharePoint Migrator runs site to site between tenants with permission mapping and a delta pass, and the wider estate moves with the Tenant to Tenant Migration Tool.

Heavy customization. When the scan report is mostly unsupported codes, the migration stops being a transfer and becomes a rebuild. Scope it properly or hand it to our cloud migration service.

A copy outside both tenants. SPMT writes into Microsoft 365 and nowhere else. Teams who want a readable copy on their own storage before cutover use the SharePoint Backup Tool, and rebuild from it later with the SharePoint Restore Tool.

When is SharePoint Migration Tool the right choice?

None of this makes SPMT a bad tool. It makes it a specific one, and inside its lane it is hard to argue with free.

• On premises to Microsoft 365. Exactly the job it was built for.
• Out of the box sites. Nothing a developer added, and no InfoPath anywhere.
• A timeline with slack in it. Rescans, reruns and manual fixes all cost days rather than money.
• A team that reads reports. The data is in the CSV. Somebody has to open it.

Mailbox heavy estates moving at the same time pair it with the Office 365 Migration Tool, and chat history needs the RecoveryTools Teams Migrator because SPMT does not touch Teams messages.

Frequently asked questions

Where to start this week

Open the documentation before the installer. Two questions settle whether SPMT limitations matter to your project at all.

First, is the source on premises? If both ends sit in Microsoft 365, stop reading about this tool and go and price the cross tenant routes instead. Second, run a scan and count the unsupported codes. That number, not the gigabyte total, tells you how long the project really takes.

Answer both and the rest of the plan writes itself. Guess at either and the weekend decides for you.

Published 5 October 2026. Limits quoted above come from the SPMT FAQ, SPMT scan risk codes, SPMT supported web parts, migration permission guidance and the SPMT release notes.