SharePoint Migration Tool, When things don’t go 100% right!

Quite a while ago I wrote an introduction post about the SharePoint Migration Tool. Recently I found myself doing a couple of migrations and found some issues that are easily resolved. In this post all the details.

There is a scan issue

When migrating large folders I was getting quite often,

There is a scan issue. Please refer to Scan Summary report for more details

There is a scan issue. Please refer to Scan Summary report for more details
There is a scan issue. Please refer to Scan Summary report for more details

When clicking on the View reports link in SPMT, I found a collection of folders and files:

SharePoint Migration Tool, When things don't go 100% right!
SharePoint Migration Tool, When things don't go 100% right! 1

When opening the ScanSummery.csv, The following message explained some of the issues:

File count ‘74675’ is too large to create index

Incremental round, Total scanned items, ... , Warning details, Error details, ...
"R1","74675", ... , "File count '74675' is too large to create index", "", ...
"R2", "74675", ... , "", "", ...

During the second round the error seems to be going away.

So even though it might look like there is an issue initially, the second round of migrations will resolve the issue where possible.

In general to avoid these kind of issue ( and therefor the tool running multiple runs of a job), I try to split my migrations into smaller jobs. Using Power Shell I might generate csv files that can then be used by the migration job for Bulk Job uploads

Scan File Failure

Within the Item Failure Reports we might find some more errors. One of the errors that I found quite often is the Scan File Failure: The parent folder was not migrated.

When checking the parent folder of the file mentioned in the report the file (and the parent folder) have been migrated and it looks like this is a false negative. The SharePoint Migration Tool however will run an additional run on these failed items and the migration should still be successful.

A file with the name … already exists. It was last modified by … on …

The A file with the name … already exists. It was last modified by … on … is one of the common warnings appearing during the first run of a migration job. This is where the migration tool identifies which files do not need to be migrated as a newer version of the file exists on the destination site already.

Errors or timeout for Server Processing the file

The following error/warning Errors or timeout for Server Processing the file: Target file already exists and cannot be replaced is again a bit of a vague message that sometimes appears in the Item Failure report

When checking the source and the destination it looks like the files are identical and once again there is a report of an issue that doesn’t seem to exist.

Try to update Indexed, EnforceUniqueValue or RelationshipDeleteBehavior

The following message in the Structure Failure Report can be a bit confusing.

Try to update Indexed, EnforceUniqueValue or RelationshipDeleteBehavior for field in a list with ItemCount exceeding the threshold.

As the SPMT is trying to ensure that both source and destination libraries have the same fields, indexes and field settings discrepancies have been found. Manually creating the indexes on the SharePoint libraries that you migrate your data to can solve this problem. You will find that this error happens when you work with very large document libraries.

As well as indexes there are a few more settings to consider. In the failure report check the field name that has been mentioned and compare this with the field in your source SharePoint library. Manually fixing the library configuration should resolve the issues.

The remote name could not be resolved: ‘hostname.blob.core.windows.net’

This error message is hidden a bit. First of all as you create a new migration job you will need to make sure that you have a SharePoint migration Tool working directory set. Then logs will be created in this folder.

SharePoint migration Tool working directory
SharePoint migration Tool working directory

After some migration jobs were failing, I found the following message in the logs:

The remote name could not be resolved: ‘spohostname.blob.core.windows.net’

The SharePoint migration tools uses this blob storage for files and in my case this was being blocked by the local DNS. When used my local laptop an nslookup gave me the ip address of this server.

Now adding that IP address and hostname to my hosts file ( you can find this in C:\Windows\System32\drivers\etc ) resolved this issue.

Anything else?

Did you come across any other issues during your migrations with the SharePoint migration tool? Then please leave a comment below.

FAQs

When can I use the SharePoint migration tool?

The SharePoint Migration Tool works for migrations from either File Shares or On-premises version of SharePoint.


Discover more from SharePains

Subscribe to get the latest posts sent to your email.

Related Posts

2 thoughts on “SharePoint Migration Tool, When things don’t go 100% right!

  1. really appreciate this post! We have ru into a lot of same issues with SPM tool The random scan failures and vague errors can be really frustrating. We’ve started using a third party tool called LinkFixer Advanced to catch and fix those pesky borken links. It gave us more control and visbility, especailly when link integrity is critical across large file sets

    1. I have used a combination of LinkFixer and custom PowerShell for my migration projects as well. In general I prefer PowerShell as it gives a little more flexibility. However, LinkFixer just does the job.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.