SharePoint Migration: 7 Costly Limits in Microsoft's Own Docs

A SharePoint migration is not a larger version of a mailbox move. A mailbox is a well-defined object with one obvious owner. A file share is twenty years of folders, a permissions model nobody has audited since the last server rebuild, and at least one path deep enough to break the tooling. This is the phase of a Microsoft 365 project that overruns — and almost every way it fails is written down by Microsoft in advance.

Every limit on this page was checked against Microsoft’s own documentation on 9 September 2026, and each one is linked where it is used. These figures move. Treat the date as part of the fact and re-read the source before planning a cutover around any of them.

What a SharePoint migration actually moves

The workload is file content: on-premises file shares and older SharePoint Server farms, landing in SharePoint Online, OneDrive and Teams. A SharePoint migration is a separate project from moving mail, and it is worth saying that plainly because the two get quoted together and only one of them is predictable.

Mail migrates as a stream of well-formed items. Files migrate as a tree whose structure encodes decisions made by people who left. The technical work is not the hard part. Deciding what the destination should look like is the hard part, and the tooling will not decide it for you.

If mail is still ahead of you, sequence it first — our write-up of the checks the EWS retirement demands covers the protocol deadlines that sit on that side of the project. The file work described here comes after it, not alongside it.

The documented limits that stop files landing

Four documented constraints account for most of the files a SharePoint migration silently leaves behind.

Path length. Microsoft’s service description is unambiguous: “The entire decoded file path, including the file name, can’t contain more than 400 characters.” A network share with a short UNC root can hide a very deep tree, and when that tree is re-parented under a site and library name, the path gets longer, not shorter. Measure the destination path, not the source one.

Invalid characters and reserved names. The characters " * : < > ? / \ | are not permitted in file or folder names, nor are leading or trailing spaces. Microsoft also reserves a set of names outright — .lock, CON, PRN, AUX, NUL, COM0–COM9, LPT0–LPT9, _vti_, desktop.ini, and anything beginning ~$. Scanned documents named with a colon in the date are the single most common offender we see.

File size. 250 GB per individual file. This is generous enough that most estates never touch it, and it is worth confirming rather than assuming, because a design file or a video archive can.

Item counts. A list or library can hold up to 30 million items. That headline number is not the one that matters. The one that matters is further down the same page, and it is about permissions.

Permissions do not copy — they are re-created

“We’ll just bring the permissions across” is the sentence that turns a two-week SharePoint migration into a two-month one. NTFS access control lists and SharePoint permissions are different models, and Microsoft documents exactly how one is translated into the other.

The mapping itself is simple. Read becomes Read, Write becomes Contribute, Full control becomes Full control. The permissions documentation then adds the line that catches people: “At this time, the special permissions, such as Deny, aren’t saved.” If your share uses an explicit Deny to carve one group out of an otherwise open folder, that carve-out does not survive. The folder arrives open.

Two more conditions are worth reading before any SharePoint migration is scoped. Migrating from SharePoint Server, “all the unique permissions on a file are migrated… Inherited permissions aren’t migrated.” And where no user mapping exists at all, “files are assigned the default permission of the location to which it’s migrated” — which means an unsynchronised directory produces a destination where everything inherits from the library and nothing is restricted.

That is the failure mode to design against. It does not throw an error. It produces a tidy-looking site where the finance folder is readable by everyone with access to the site.

There is a scale limit here too, and it is the one to plan around. Microsoft’s SharePoint limits page puts the supported number of unique permissions in a list or library at 50,000, “however, the recommended general limit is 5,000”. It also states that once a list, library or folder passes 100,000 items you cannot break permissions inheritance on it at all. A file share where every third folder has its own ACL will generate unique permissions at a rate that reaches those numbers faster than anyone expects.

Migration Manager or the SharePoint Migration Tool?

Both are free, both are Microsoft’s, and the difference is not subtle once you know it. People search for these by name, so it is worth being precise.

Migration Manager lives in the SharePoint admin centre and is built for scale. You install lightweight agents on servers or virtual machines, group them, and it distributes tasks across them. Its documentation is aimed squarely at file shares, and it also covers Google Workspace, Box, Dropbox and Egnyte. The source server must support SMB 2.0 or higher, and you need Global admin or SharePoint/OneDrive admin rights on the destination.

The SharePoint Migration Tool is a desktop application, and its reach is different: SharePoint Server 2010, 2013, 2016 and 2019, SharePoint Foundation 2010 and 2013, and file shares. It is the one that handles on-premises SharePoint sites rather than raw shares, including web parts, navigation, content types and term stores. It also migrates SharePoint 2010 out-of-the-box workflows and SharePoint Designer 2010 and 2013 workflows — note the versions, because anything newer is not on that list.

One authentication note in the SharePoint Migration Tool documentation reliably surprises people: “If the on-premises server is configured to support multiple authentication providers, including Windows authentication, then Windows authentication is not supported.” That is a farm-configuration fact, discovered on the day, unless someone checks first.

Underneath both sits the SharePoint Migration API, which is also what the commercial third-party tools use. That matters more than the tool choice: whichever you pick, you are queueing jobs against the same service under the same limits, so a tool cannot buy you throughput that the platform does not offer.

Throttling is deliberate, and Microsoft will not lift it

This is the section that ruins weekend plans, and it is also where the received wisdom is half right. In Microsoft’s own classification a SharePoint migration is a background application, sitting in the same bucket as backup and data loss prevention tooling.

SharePoint Online throttles applications that make too many requests, returning HTTP 429 or 503 with a Retry-After header. The throttling guidance is explicit that retrying anyway makes it worse: “Throttled requests count towards usage limits, so failure to honor Retry-After may result in more throttling.”

Microsoft’s migration performance guide goes further and says the quiet part out loud. Tighter throttling limits are applied to background applications — migration, data loss prevention and backup tools — during weekday daytime hours, and capacity opens up during evening and weekend hours for the region. Then, under its own heading: “Can Microsoft turn off the throttle to help me with migration? No.” Throttling rules cannot be disabled or suspended, and opening a support ticket does not lift them.

So the weekend cutover instinct is right, for a reason most people have not read. What is wrong is the assumption that a weekend is therefore enough. Here are the ceilings Microsoft publishes:

Read those as ceilings rather than forecasts. The same API documentation states that jobs are processed “on a best-effort basis, without Service Level Agreement (SLA) or guaranteed performance”. A design library of 50 kB CAD files with custom columns sits in the bottom row, not the top one.

Three things reliably help. Use app-based authentication, because Microsoft says directly that running a SharePoint migration in user mode “triggers increased throttling, resulting in poor performance”. Keep fewer than 5,000 jobs queued at once. And stop the OneDrive sync client on the machines involved — the throttling guidance names sync running alongside migration tooling as a cause of exactly this problem.

The lift-and-shift trap

Every constraint above becomes easier if you move less. This is the one judgement in a SharePoint migration that no tool makes for you, and the temptation is always to reproduce the existing folder tree exactly so nothing feels different on Monday.

Do that and you inherit every problem the file server had, plus new ones. Deep trees are what breach the 400-character path limit. Per-folder ACLs are what generate unique permissions at scale. A single library holding everything is what runs into the list view threshold — Microsoft’s support documentation notes that “when a list view shows more than 5,000 items, you might run into a list view threshold error”.

Microsoft’s own performance guide opens with the same argument, framed as a cost question: “The first rule of a good migration is to know your source; evaluate and triage your content before you migrate. What content really needs to be migrated? What can be left behind? How many file versions should be included?”

That is not housekeeping advice. Content you leave behind costs nothing to move, breaks nothing on arrival and never needs re-permissioning. Archive-and-shrink is usually the highest-return decision available, and it is made before any tool is opened.

The order that works

The sequence below is deliberately front-loaded. In a SharePoint migration, everything cheap happens before anything irreversible.

Scan first. Both Microsoft tools have a pre-scan, and the SharePoint Migration Assessment Tool exists specifically to report what will fail before anything moves. Remediate names and paths at the source, where a bulk rename is trivial. Design the destination as sites and libraries rather than as a copy of the tree. Pilot with one department that has a real permissions problem, not the easiest one. Then bulk-move during off-peak hours, run incremental passes to catch changes, and cut over.

One instruction from the Migration API documentation is worth following literally: “To avoid migration issues, deactivate the target site for users until migration completion.” Users writing into the destination while it is being loaded is a genuinely unpleasant reconciliation problem.

How long it takes, and what it costs

We are not going to publish a duration or a price for a SharePoint migration here, and the reason is in Microsoft’s own wording rather than in ours.

The throughput table above is a set of maximums under ideal conditions, on a service Microsoft explicitly describes as best-effort with no SLA. The performance guide also observes that in practice “the typical bottleneck is from source reading” — the disk, the RAM and the antivirus on the machine doing the reading, none of which anyone can know from the outside. A day rate multiplied by a terabyte count is a guess with a decimal point in it.

What genuinely moves the number is knowable, though, and it is the same list our Microsoft 365 migration services page uses for scoping: volume of file data and where it sits, how many integrations authenticate against the old platform, the identity model, and how much documentation already exists. An estate with a current inventory is cheaper to move than one without, because discovery is shorter and there are fewer surprises mid-project.

That is why discovery is scoped as its own fixed piece of work. It ends with a written plan and a real number, and you keep both regardless of who does the migration.

When this is the wrong project

Three cases where a SharePoint migration is the wrong answer, and we would rather say so early.

The real problem is one application. If a single line-of-business system needs a mapped drive, moving the whole share to the cloud does not solve it and may make it worse. Fix the application question first; it sometimes removes the reason for the project entirely.

The data is genuinely hostile to the platform. Very large working sets that are opened over the network all day — video editing, some CAD and GIS workflows, database files on a share — are a poor fit. SharePoint and OneDrive are document collaboration services, not a general-purpose network file system, and pretending otherwise produces a slow, unhappy result nobody can fix afterwards.

Nobody owns the information architecture. If there is no one willing to decide what gets left behind and who should see what, the project will default to lift and shift, and lift and shift is how you spend real money to arrive exactly where you started. Sort the ownership question before the tooling question.

What to do this week

Run a scan. Not a plan, not a quote — a scan. The assessment tooling is free, it reads without changing anything, and it converts an argument about effort into a list of files with problems.

Then read the permissions on your top three shared folders and ask who should actually have access, rather than who currently does. A SharePoint migration is the cheapest moment you will ever get to fix that, because everything is moving anyway — the same argument we make about identity and the gaps MFA alone does not close, and the reason security belongs inside the migration plan rather than in a phase after it.

If you want that assessment done for you, that is what a scoped discovery buys, and it is the same first step whether the destination is SharePoint, OneDrive or Teams.