# SPMT limits: file size, item count, and what actually fails > Most lists of SharePoint Migration Tool limits online are unsourced, undated, and written by companies selling you something else. Here are the real numbers with the Microsoft page and date behind each one, plus the error message that tells you the wrong thing about where your problem is. [Home](https://tenantcraft.ca/) [Insights](https://tenantcraft.ca/insights) Migration Execute Sep 9, 2026 9 min read Geri Crroj Microsoft 365 consultant, Niagara, Ontario Your migration has been running for six hours. Two libraries have failed. The report says: > There isn’t enough disk space in the target site collection. So you open the SharePoint admin center and check the site. There is plenty of room. You check the tenant. Also fine. You add storage anyway, rerun the job, and it fails again with the same message. That error is pointing at the wrong machine. It usually means **your own computer** has run out of space in the folder SPMT uses to package content before uploading it. Not the destination site at all. That is the shape of most SPMT trouble. The limits are real and knowable, but the tool’s own messages send you looking in the wrong place, and most of what you find online is written by companies selling a different tool. The five minute version - **250 GB** per file. **400 characters** for the whole decoded path including the file name. - **30 million** items per library. The famous **5,000** number is a view threshold, not a storage limit. - **50,000 major versions** per item, and **5,000 unique permissions** per list as the recommended ceiling. - SPMT **does** migrate permissions, versions and managed metadata. The blogs saying otherwise are out of date. - It stalls because of **throttling**, which Microsoft will not switch off for you, not even with a support ticket. ## The actual limits, with dates Every number below comes from Microsoft’s own pages. I have put the page date next to each group so you can tell how fresh it is, which is the thing most lists leave out. From the **SharePoint limits service description** (ms.date 2025-05-29, page republished 2025-12-02): | Limit | Number | Worth knowing | | --- | --- | --- | | File upload | **250 GB** | Per individual file | | File attached to a list item | **250 MB** | Different from the library limit | | Whole file path | **400 characters** | Decoded, folder path plus file name | | Items per library | **30 million** | Files and folders | | Items per list | **30 million** | | | Unique permissions per list | **50,000 supported, 5,000 recommended** | The recommended number is the one that matters | | Versions | **50,000 major, 511 minor** | | | Storage per site collection | **25 TB** | | | Lists and libraries per site collection | **2,000** | | | Breaking permission inheritance | Blocked above **100,000 items** | On the list, library or folder itself | Two of those cause more grief than the rest. **The 400 character path** is the one that quietly eats files. It is not the file name, it is the entire decoded path with the name on the end. A tidy-looking file three folders deep on a long site URL can be over it without anyone noticing. When it goes over, the file does not arrive. **The 5,000 recommendation on unique permissions** is not the same as the 5,000 you have heard about. That other one is the list view threshold, which is about how many items a view can display, not how many a library can hold. A library can hold 30 million. A view chokes at 5,000 without an index or a filter. People conflate these constantly, then conclude their migration failed when the content is sitting there fine and only the default view is broken. ## What SPMT actually migrates This is where most of the internet is wrong, and it is worth being blunt about why. Search “SPMT limitations” and nearly every result is published by a company selling a competing migration tool. Several of them state things Microsoft’s current documentation directly contradicts. Per Microsoft’s **what does SPMT support** page (ms.date 2026-08-17), SPMT migrates: - Files, folders and list items - **Permissions**, with separate settings for file share and SharePoint on-premises permissions - **Versions**, and you choose how much history comes across - **Managed metadata and taxonomy**, including content types and term stores - Site navigation and icons, site features, and SharePoint web parts - Pages in the site asset library - **Incremental runs**, so you can rerun a task and move only what changed Two claims you will read that are not true **“SPMT doesn’t do incremental migrations.”** It does. Microsoft’s supported-features list includes incremental runs, and it has for years. Save the task, rerun it, and only new or changed files move. **“SPMT doesn’t migrate permissions or metadata.”** It does both. They are named rows on the same page. Check the date on whatever you are reading. A 2019 blog post about SPMT is describing a different product, and a vendor blog has a reason to leave it uncorrected. What SPMT genuinely will not do is anything custom. Microsoft’s wording is precise: out-of-the-box sites “that don’t use any coding or third-party tools” can be migrated. Full-trust solutions, SharePoint Designer workflows and InfoPath forms are rebuilds, not moves. That limit is real and no tool changes it. ## Why it stalls Almost every “SPMT is so slow” complaint is throttling, and throttling is deliberate. > Throttling is in place to protect the reliability and availability of the service. Throttling rules can’t be disabled or suspended. Opening a support ticket doesn’t lift throttle. Microsoft Learn, Migration performance guide for SharePoint and OneDrive Microsoft throttles background work harder during weekday daytime hours in your tenant’s region, and eases off evenings and weekends. That is most of the reason a cutover happens on a Saturday. The published throughput ceilings (ms.date 2025-09-16, republished 2026-05-20) explain the rest: | Content type | Example | Ceiling | | --- | --- | --- | | Light | ISO files, video | **10 TB/day** | | Medium | List items, Office files around 1.5 MB | **1 TB/day** | | Heavy | List items with custom columns, small files around 50 KB | **250 GB/day** | That is a **40 times** spread, and file size is what moves you along it. Big files migrate faster than small ones. Files migrate faster than list items. So a 500 GB library of video finishes overnight, and a 500 GB library of 50 KB scanned invoices does not finish that week. If your migration is crawling, measure your average file size before you blame the tool. It is usually the answer. Three more things from the same page that change what you do: - **Package at least 250 files per transfer**, and keep each package between 100 MB and 250 MB. - **Never queue more than 5,000 migration jobs.** Microsoft is specific that this means jobs sitting _in the queue_, not jobs processing. Over-queuing loads the database and slows everything down. - **Use app-based authentication.** Migration is a background task. Running it in user mode triggers heavier throttling than normal. ## Reading the errors properly Two error messages come up constantly, and both are misleading. **“There isn’t enough disk space in the target site collection.”** This is the one from the top of this post. It reads as a destination problem and is usually a local one: the drive on your migration machine has filled up with the packages SPMT builds before upload. Check the free space on the machine running SPMT and on its temp folder first. Then check the site and tenant quota, in that order, because the cheap check is the one that is usually right. **“Not all the items in the package have been migrated.”** This is a summary, not a cause. The real reason is in the failure report, item by item, with correlation IDs. Open the report. Nearly always it is a handful of files over the 400 character path limit, or blocked characters, or something locked open at the source. When the 503s are genuinely Microsoft's problem If you are seeing a high volume of HTTP 503 “Server Too Busy” responses **during evening and weekend hours**, that is outside the expected throttling pattern and Microsoft treats it as escalation-worthy. Raise a ticket with how much migration is left in TB, your start and end dates, where you are migrating from, roughly how many throttles per hour and exactly when, and which tool you are using. Daytime 503s are just throttling working as designed, so there is no point raising those. One genuine bug worth knowing if you are coming off an old farm: OneNote notebooks migrated from **SharePoint Server 2010** lose every attachment over 100 KB, because 2010 stores them in a folder with a content type SPMT cannot read. Microsoft’s own workaround is to hop through SharePoint Server 2016 first. ## The pre-flight check that prevents most of this Twenty minutes before you start beats a weekend of retries. Look for: 1. **Paths over 400 characters.** Find them in the source and shorten the folders, not the file names. 2. **Average file size per library.** Under about 100 KB, plan for the 250 GB/day tier and stop expecting more. 3. **Libraries over 100,000 items** where somebody will later want to break permission inheritance. They cannot, once it is that big. 4. **Free disk space on the migration machine.** The thing that actually caused the error at the top of this post. 5. **Anything custom.** Workflows, InfoPath, full-trust code. Those are rebuild line items, not migration ones. SPMT’s own scan reports content and structure risks, including unsupported workflows, item counts and unique permissions over the limit. Run it. Just know it reports risks rather than fixing them, and it will not give you an identity map. ## When to stop fighting it Sometimes the honest answer is that the tool is not the problem and neither are you. If you are moving **tenant to tenant**, SPMT is the wrong tool entirely, because it migrates from on-premises sources. Microsoft’s cross-tenant SharePoint migration is still in private preview. That is the clearest case for paying: ShareGate Migrate starts at **$5,995 USD a year** for one machine, with a 15-day trial. The [full tool comparison](https://tenantcraft.ca/insights/sharepoint-migration-tool-vs-sharegate) covers where each one earns its money. But if you are on SharePoint Server, under a few hundred sites, and hitting the limits above, a paid tool will hit exactly the same limits. They all use the same Migration API. They all get throttled the same way. **The 250 GB file cap, the 400 character path and the throughput ceilings are SharePoint’s, not SPMT’s.** Paying gets you better reporting and better handling of the failures. It does not get you a bigger ceiling. 01 What is the maximum file size SPMT can migrate? **250 GB per individual file**, which is SharePoint's upload limit rather than a tool limit. A file attached to a list item is capped much lower at 250 MB. Both figures are from Microsoft's SharePoint limits service description, ms.date 2025-05-29. 02 Does SPMT migrate permissions and metadata? Yes to both, despite a lot of blog posts saying otherwise. Microsoft's "what does SPMT support" page (ms.date 2026-08-17) lists permissions, with separate settings for file share and SharePoint on-premises permissions, along with versions, managed metadata and taxonomy, content types and term stores. It also supports incremental runs, which is the other claim commonly repeated as a limitation. 03 What is the 5,000 item limit in SharePoint? It is a _view_ threshold, not a storage limit. A library holds up to 30 million files and folders. What breaks at 5,000 is a view trying to display that many items without an indexed column or a filter. Separately, 5,000 is Microsoft's _recommended_ ceiling for unique permissions in a list, where 50,000 is the supported maximum. Three different 5,000s, which is why this gets muddled. 04 Why is my SPMT migration so slow? Usually small files plus throttling. Microsoft's published ceilings run from 10 TB/day for large files down to 250 GB/day for small files around 50 KB and list items with custom columns, a 40 times spread. Microsoft also throttles background tasks harder on weekday daytimes and will not lift it, even on a support ticket. Migrate evenings and weekends, keep packages between 100 MB and 250 MB, and never queue more than 5,000 jobs. 05 SPMT says there isn't enough disk space in the target site collection, but there is. What now? Check the migration machine, not the destination. That message commonly means the local drive holding SPMT's packaging folder has filled up. Confirm free space on the machine and its temp folder first, then the site and tenant quota in the SharePoint admin center. If all three are fine, update SPMT and retry in smaller batches, and pull the correlation IDs from the failure report before opening a ticket. ## Bottom line The limits are published, stable and mostly not SPMT’s. 250 GB a file, 400 characters a path, 30 million items a library, 50,000 versions, 5,000 unique permissions recommended. Write those five on a sticky note and you have most of it. The rest is knowing that the errors point in the wrong direction. Disk space means your machine. “Not all items migrated” means open the report. Slow means small files, and small files mean 250 GB a day whatever you paid for the tool. Check your paths and your average file size before the weekend, not during it. The inventory that catches these before you start SharePoint Discovery & Inventory Worksheet PDF · 7 pages [Email me the PDF](https://tenantcraft.ca/resources/guides/sharepoint-discovery-inventory) TWENTY MINUTES, NO PITCH ## Tell me what is stuck. I will tell you what it takes. Same consultant from the first email to the last cutover. If I am not the right fit, I will refer you to someone who is. [Book a 20-min call](https://tenantcraft.ca/contact) [See published rates](https://tenantcraft.ca/pricing) --- _Canonical HTML: https://tenantcraft.ca/insights/sharepoint-migration-tool-spmt-limits · Agent guide: https://tenantcraft.ca/llms.txt · Site map: https://tenantcraft.ca/sitemap-index.xml_