# SPMT migration errors: the codes you will actually hit and how to fix them

> Microsoft splits the SharePoint Migration Tool error codes across five pages, and none of them tell you which failures stop the job and which ones quietly skip a file and carry on. This is the lookup table, the five failures behind most of the codes, and the one category SPMT does not give you a code for at all.

[Home](https://tenantcraft.ca/)  [Insights](https://tenantcraft.ca/insights)  Migration

Execute Sep 13, 2026  11 min read

Geri Crroj

Microsoft 365 consultant, Niagara, Ontario

It is late, the cutover window is half gone, and the SharePoint Migration Tool has stopped on a line that reads:

> Invalid site URL ‘[http://intranet.contoso.local](http://intranet.contoso.local)’ (ErrorCode: 0x0201000F)

So you paste the URL into a browser. It opens. You paste it back into SPMT. Same code.

That is the shape of almost every SPMT error. The message names a thing, and the thing it names is fine. What is broken sits one step to the side.

Microsoft does publish the codes. They just live on five different pages, sorted by which part of the product emitted them. None of those pages answer the question you have at 11pm. Is this stopping the job, or is it skipping files and carrying on without telling me?

## Five causes, wearing thirty different codes

Once you group the published codes by what actually causes them, the list gets short. Nearly everything in Microsoft’s table is one of five failures.

![A three column table grouping SharePoint Migration Tool error codes by their real cause. Five rows: wrong account, your own machine, target does not match source, content breaks a limit, and service or transfer. Each row lists the hex codes in that family and the action that fixes them.](https://tenantcraft.ca/images/spmt-err-01-causes.png)

Error codes, regrouped

Microsoft sorts these by component. Here they are sorted by what you have to go and change instead. Checked against the SPMT error list in September 2026.

Work the family, not the code. If you get `0x02040012`, the fix is not “look up 0x02040012”, it is “my migration machine is out of room”. The next three codes you hit will have the same answer.

## The account is the first thing to check, every time

More SPMT failures come down to permissions than to anything else, and they arrive wearing four or five different codes.

`0x02010017` is the honest one. It says you must be a site collection admin, and it means it. `0x02010016` says it cannot find your SharePoint Server user. `0x0201000C`, `0x02010018` and `0x02030001` all resolve to some version of “check your credentials and try again”.

The fix is the same in each case, and both halves get forgotten:

1.  The migration account needs site collection administrator on the **source**, not just the target.
2.  Sign out of SPMT and sign back in after you change anything. SPMT caches the token, and a permission you granted five minutes ago is not in it.

This is also where `0x0201000F` usually lands. Microsoft’s advice for that code is to check the URL is valid and open it in a browser. That is exactly the test that passes. You can open the site because you are you. SPMT is running as a different account, and that account has no rights there. Check who SPMT is signed in as before you touch the URL.

One case where the URL genuinely is the problem

`0x0201000F` also fires when the source is reachable from your desk but not from the migration server, which happens with split DNS, or a host entry that exists on one machine and not the other. Test the URL **from the machine running SPMT**, in a browser on that machine, signed in as the migration account. If that fails, it is a network problem and no amount of SPMT configuration will help.

## The disk that fills up is yours

Five codes point at the SPMT working folder, and the folder is on your computer, not in Microsoft 365.

`0x02040012`, `0x0204000A`, `0x0204000D`, `0x02050001` and `0x02080001` all resolve to the same folder:

```
%appdata%\Microsoft\MigrationToolStorage
```

SPMT builds a package there before it uploads anything, so a 400 GB library needs somewhere local to stage.

Microsoft’s guidance for most of these is that every file and folder in that working folder must be closed. What that means on a real machine:

-   Free space on whatever drive holds `%appdata%`, which on a laptop is usually the same C drive that is already nearly full.
-   Antivirus that is scanning the folder counts as having the files open. Exclude the path.
-   Do not open the working folder in Explorer to see how it is going. That is enough to corrupt the local storage and earn `0x02050001` on the next run.

One more in this group deserves a mention, because the fix is not where you would look. `0x02010020` means the source has version history and the target library does not have versioning switched on. You either turn versioning on at the destination or turn version history off in SPMT’s settings. This is also the strongest argument for letting SPMT create the target list rather than building it by hand first: a list you made yourself is where template mismatches (`0x02010010`) and unsupported templates (`0x02010023`) come from.

There is a related message that sends people in entirely the wrong direction: _“There isn’t enough disk space in the target site collection.”_ It reads as a tenant quota problem and it is almost always this same local folder. I covered that one, along with the published tool ceilings, in [SPMT limits: file size, item count, and what actually fails](https://tenantcraft.ca/insights/sharepoint-migration-tool-spmt-limits).

## Unique ID and IRM: the failures with no code of their own

These two failures confuse people for the same reason. Microsoft’s error table has no entry for either of them.

**Information Rights Management.** If IRM is switched on for a source library, the migration tool reads the files the same way a person does, which means it receives them encrypted. It then uploads the encrypted blob. The files arrive, the job may well report success, and nobody can open anything.

Microsoft’s instruction is explicit and it is a sequence, not a setting:

1.  Disable IRM on the source list and on the target list.
2.  Run the migration.
3.  Enable IRM again on both.

IRM settings themselves are not migrated, so step 3 is yours to do by hand. Microsoft’s migration assessment scan produces an `IRMEnabledLibrary-detail.csv` listing every library with IRM turned on. Run the scan and work that file before your cutover, because you cannot tell by looking at a library whether it is protected.

**Unique IDs.** The other half of this is item identity. Every item in SharePoint carries an internal unique identifier. SPMT does not preserve the source one, so a migrated file arrives with a new identity. That is fine until something in the target already holds the spot. You get `0x01710004`, and Microsoft’s own description of it is the most useful line in the error table:

> Fail to look up folder name. The item may exist in other list or site in the same site collection. Or the item is in the recycle bin.

The recycle bin half catches people constantly. You deleted a test library, reran the migration, and the name is still held by the deleted copy. Empty the second-stage recycle bin on the target site collection and rerun.

About the hex codes you will find in forums

Search for SPMT and IRM and you will find `0x03000027` and `0x0300001E` quoted confidently in community answers. Neither appears in Microsoft’s published error table. They may well be real, but I am not going to tell you a code is official when I cannot find it on a Microsoft page. Fix the IRM sequence above and the codes stop mattering.

## Throttling, 429, and the 100,000 number that is not about throttling

If your migration is crawling rather than failing, you are being throttled.

Throttling is not negotiable. SharePoint returns HTTP 429 (“too many requests”) or 503 (“server too busy”) with a `Retry-After` header telling the tool how long to wait. Microsoft is blunt about the rest:

> 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.

Retried requests still count against your limits, so hammering the retry button makes the throttle last longer. The per-user ceiling is 3,000 requests per 5 minute window. Microsoft throttles background work like migration harder during weekday daytime hours and eases off evenings and weekends, which is the real reason cutovers happen on Saturdays.

Now a correction, because the internet has this one wrong. You will see **100,000** quoted in throttling advice, as though a list crossing 100,000 items starts triggering 429s. It does not. The 100,000 threshold is a permissions limit. Above that item count you cannot break permission inheritance on a list, library or folder, and you cannot reinherit it either. Individual items inside it can still carry unique permissions.

That matters for a migration, just not the way the throttling posts suggest. If your plan involves migrating a 150,000 item library and then breaking inheritance on it to set up access, the plan does not work and no error code will tell you why until you try. Split the library first.

The limits that do shape a migration, all from Microsoft’s own pages:

| Limit | Number | What breaks |
| --- | --- | --- |
| Items per list or library | 30 million | Migration fails above this |
| Break permission inheritance | 100,000 items | Cannot break or reinherit above this |
| Unique permissions per list | 50,000 supported, 5,000 recommended | `0x02030003` |
| Add a column index | 20,000 items | Warning only, migration continues |
| Whole path, including file name | 400 characters | File is skipped |

## Long paths are skipped, and nothing tells you

This is the failure that costs people the most, because it does not look like a failure.

SharePoint allows 400 characters for the entire decoded path including the file name. Meet a file over that and SPMT does nothing clever. It will not shorten the name or flatten the folders, and it does not retry. It writes one line in the failure report, moves to the next file, and the task finishes.

![Two panels side by side. The left panel, headed stops the task, lists invalid site URL, not a site collection admin, working folder full or locked, unsupported list template and parent folder not migrated. The right panel, headed skips the item and carries on, lists paths over 400 characters, checked out files, blocked characters, thicket folders and unsupported web parts.](https://tenantcraft.ca/images/spmt-err-02-stop-vs-skip.png)

What a failure costs you

The right column is the dangerous one. Those tasks complete, and the missing files surface weeks later. Checked against Microsoft's SPMT error and scan documentation in September 2026.

Everything in that right column behaves the same way. A file checked out at the source (`0x0131000F`) is skipped. A folder ending in `_files` is skipped, because SharePoint treats it as a thicket folder and refuses to create it. Blocked characters produce `0x0201000E` and that item is skipped.

So the validation step after a migration is not optional, and it is not “does the site look right”. It is a count. Compare item counts per library, source against target, and read the failure report line by line. A task that says it succeeded has told you nothing about whether everything arrived.

Fix long paths at the source, and shorten the **folder** names rather than the file names. Nobody can find a file you renamed, and one shortened folder near the top fixes hundreds of items at once.

## When SPMT will not install at all

A smaller problem, but it wastes an afternoon when it hits. Microsoft lists the requirements and most of them are things nobody checks:

-   The machine must be **x64**.
-   .NET Framework **4.6.2** or higher.
-   Microsoft Visual C++ 2015 Redistributable for x64. SPMT bundles most of what it needs and misses some system DLLs, so installing the redistributable separately resolves dependencies the installer cannot.
-   Stop third party antivirus before you install.

If you get _“Application SharePoint Migration Tool is already installed from another location”_, that is a half-finished previous install. Uninstall, then reinstall. The current released build at the time of writing is **4.1.130.4**, and if a documented fix is not behaving, checking your version is a faster test than most of the alternatives.

## What this does not fix

Reading codes correctly does not make the tool do things it cannot do.

SPMT migrates from on premises sources. It is not a tenant to tenant tool, and no error code will tell you that politely. If you are moving between tenants you are in a different product category.

It will not rebuild anything custom. InfoPath forms, 2013 workflows, full trust code and custom web parts appear in the scan as risks, not as items with fixes. Those are rebuild line items and they belong in a separate budget.

And the throughput ceilings are SharePoint’s, not the tool’s. Every migration product uses the same Migration API and gets throttled the same way. Paying for a commercial tool buys you better reporting and better handling of failures. It does not buy you a faster ceiling.

And if you hit a code with no cause listed here, escalate it rather than guessing. Pull the correlation ID out of the failure report first. Support asks for it immediately, and it never appears in the on screen message.

## The bottom line

Stop looking up the code and ask which of the five families it belongs to. Check the account first and your own disk second. Then treat any task that “succeeded” as unverified until you have compared item counts and read the failure report.

The expensive failures are the quiet ones. A skipped file writes a line in a report nobody opens, the task goes green, and you sign off on a migration that is missing content. That bill arrives weeks later.

Most of these codes are avoidable. The inventory worksheet finds long paths, oversized lists and IRM libraries before the cutover window, not during it.

SharePoint Discovery & Inventory Worksheet

PDF · 7 pages

[Email me the PDF](https://tenantcraft.ca/resources/guides/sharepoint-discovery-inventory)

01 What does SPMT error 0x0201000F mean?

Invalid site URL. Microsoft's advice is to check the URL opens in a browser, which usually passes and sends people in circles. In practice it is nearly always the account rather than the address: the account SPMT is signed in as does not have site collection administrator rights on the source. Fix the permission, then sign out of SPMT and back in so it picks up a fresh token. If the account is right, test the URL from the machine running SPMT rather than from your own desk, because split DNS and stale host entries produce the same code.

02 Why does SPMT say there isn't enough disk space when the site has plenty?

Because the message is about your computer. SPMT builds packages in the MigrationToolStorage folder under %appdata% before uploading, and that folder sits on your local drive. Codes 0x02040012, 0x0204000A, 0x0204000D, 0x02050001 and 0x02080001 all point there. Free space on that drive, exclude the folder from antivirus, and do not open it in Explorer while a migration is running.

03 Can Microsoft turn off throttling for my migration?

No. Microsoft's migration performance guide states that throttling rules cannot be disabled or suspended and that opening a support ticket does not lift throttle. Throttled requests still count against your limits, so aggressive retries extend the throttle rather than beating it. Migrate during evenings and weekends in your tenant's region, and use app based authentication, because migration run in user mode is throttled harder.

04 Does SPMT shorten file paths that are over 400 characters?

No. It skips the item, writes it to the failure report, and continues. The task can finish and report success with files missing. Fix long paths at the source before you migrate, and shorten folder names rather than file names so one change clears many items. Then validate by comparing item counts per library, source against target, rather than trusting the task status.

05 Why won't the SharePoint Migration Tool install?

Four things account for most install failures: the machine is not x64, .NET Framework is below 4.6.2, the Microsoft Visual C++ 2015 Redistributable for x64 is missing, or third party antivirus is interfering. Install the redistributable separately, since SPMT bundles most dependencies but can miss system DLLs. If you see "already installed from another location", uninstall the previous copy and reinstall.

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/spmt-migration-errors · Agent guide: https://tenantcraft.ca/llms.txt · Site map: https://tenantcraft.ca/sitemap-index.xml_