Sometimes moving mailboxes fails, and it can be for the strangest reasons. Many reasons are quite easy to identify, but some are a real pain! Here is a quick guide to diagnosing the root cause of the problem, following the process I used to identify and fix some failed migrations.
In my instance I had a specific set of mailboxes that couldn’t make it past 10% when migrating from Exchange 2013 down to Exchange 2010 (don’t ask!), they just failed at the synchronising folders stage. The jobs would sit with either a ProxyBackoff or TransientFailure error message, retrying until they eventually (after a few hours) reached the maximum retry count and failed to migrate with the status FailedStuck.
When viewing the mailbox move via the command “Get-MoveRequestStatistics” it really doesn’t tell you anything.

However the command “Get-MoveRequestStatistics –IncludeReport | fl” does give you a lot more information. The FL shows a lot more fields, this can be helpful if you simply have a job that doesn’t seem to be making process, as often the status is reported as “In Progress” but the StatusDetail may be “ProxyBackoff” showing that it isn’t actually doing anything!

The real goldmine of information comes from the Report property:

And then comes the failure line in the report:

This serious of events is repeated over and over again. It really doesn’t tell you what is going wrong! Often the report contains some great information, but at times like this I’d really like to know what this error actually relates to – mostly because it isn’t transient, it happens every retry!
What is really easy to miss is that the report is not just a bunch of text, it is actually an object with a lot more information help inside of it. If you want to see absolutely everything the easiest way is to export it to an XML file. You can complete this quite easily by running the command:

Which will give you an output something like this:

This is great if you want a quick way to view all the possible information, however far more useful is just getting at the errors. This file does contain them, but if you just want to access the errors then the following is far easier:

As this will display just the errors that you hit, like this:

This gives far more information that can help you find the root cause of the problem, such as CommunicationErrorTransientException, and some reporting from the server. Looking at the end of the DataContext can be really helpful in pinpointing the folder or item that is causing the failure where the issue relates to a specific item. In this instance:

The above shows that there is a problem folder within the Finders. So this is where we look first, and the simplest way to fix this is to get the user to run “Outlook /CleanFinders”. In my case this appears to have solved the problems and the mailboxes migrated. If it is a little more complex, then using MFCMAPI may be your only way to remove the problem item.
The most useful element of this is that the report is not just a wall of text as it first appears, but a complex series of objects that contain a whole lot more information than it first appears, and is really useful for diagnosing migration issues.