Incremental Migration of Error Items Only & Retry
The idea is to use the migration report to start a new migration of the files that error out only, instead of running a full incremental migration.
As much as we really like this idea, it doesn’t fit in the current narrative of ShareGate Desktop.
We will for sure reevaluate this one in a near future.
if I migrate complete sites to another site then I mostly have some lists which could not be migrated on the first run. If I start the migration again then migration is successfull.
My problem is that I always have to copy the complete site again with copy and replace and that tooks time.
It would be better if I would be able to select automatically the unsuccessfull lists and then try only to copy the lists that throws an error on first run.
Is there an option that Sharegate automatically choose the unsucessfull lists (error) from the migration report and only start a new try for that lists and not for the whole site?
Feedback sent from the Migration report view.
As someone new to ShareGate migration, this feature would certainly make my job easier.
my videos my commented
If you see the error log and files that error out are from selected folders.
As a workaround you can run incremental migration for only these folders, Better than running full migration
Boooo - c'mon 'Toine this would be LEGENDARY.
How can this not be a priority feature...?
1 Please make logs searchable like if I type Steve_Davis I would be able to see the log for Steve_Davis.
Pleae give a cmdlet or a button to retry errors. It is great that you can narrow down a failed attempt, maybe it was a network blip or something that would be corrected if that file was auto retried at the end of the run or a remediation run is auto-kicked off. It would be hugely helpful.
Feedback sent from the Tasks view.
The ability to migrate content base on previous migration log. For example migrate only the items with an error message.
When I am doing a migration, it would be nice to click on the "failed" and have them "tried again" as I have versions major and minor and didn't have MINOR turned on. I just turned it on and I would like to try it again if the system could keep track of what "failed" and allow me to try again.
Matts Computers SA commented
Really need this to reduce the administration on migration!
Vaibhav Kaulkar commented
The failed items only need to be copied. E. G my list has not copied look up columns, then only copying data in lookup columns need to be allowed
Marino Valentino commented
....waiting now about 4 yrs on this... c'mon Sharegate..... I believe in you
It is frustrating to have to go back a screen or two to retry a move when there are only a few "warning" or "errors" that resulted from the move. It would be great if from the results screen , if there was a option to right click a line item that had an issue and click retry.
You would do this after making the appropriate changes to correct the issue of course. But having to go back and trendge through processing all of the other items (even though you click incremental). It still takes time to compare the last changed dates, which means more time waiting.
Where as if you could just kick it off right from the result page, it would make things a lot faster.
Feedback sent from the Migration report view.
Viktor Vallin commented
Is there any progress with this? Struggling with this almost daily..
It would be very helpful to have a better option to retry all errored items of a content migration. Otherwise you need to search for every single ID or do a huge delta copy (and that takes very long, when its a big list)
the frustration is when the import portion fails on the Microsoft side. At least having those auto retry a few times would be helpful.
When you have items that failed for unknown reason/threshold/import type reason. Would love to be able to grab those in the filter and manually retry. Or, have settings in job to retry 5 times. Or something similar. When we have large lists it is very difficult to hunt those down and hand pick them to retry.
I see this (in addition to recycle bin) a MUST. When you have tens of Gigabytes and more than thousand files fails, you just need to retry the whole thing again and will fail again.
This is a Must, please!
+100 to Anikke - this is painful finding these errors and redoing the entire migration is definitely overkill and can actually introduce errors.
Anikke Bukowski commented
This is a real shame, particularly after the initial response from @Natalie. Having to redo a migration in its entirety, or trying to manually find the items that have errored by their ID to remigrate them is time-consuming and painful. Is there a technical blocker for this feature?
Frankly, I'm very surprised at the Admin response of "it doesn’t fit in the current narrative of ShareGate Desktop". I would consider addressing Sharegate Desktop migration failures as one of the top priorities, exceeded only by more reliable initial migrations.
We routinely encounter issues with migrations. Some may not copy because of a timeout or throttling issue. Some may incorrectly report access denied, but work successfully on subsequent attempts. There may be some errors that will require changing specific settings to address the issue. However, the bulk of the errors can be addressed by re-migrating the failed content in Normal mode with Overwrite specified. Without Overwrite, another incremental may not address the problem, since the time stamp of a partial copy will likely be the same as the source, or a newer timestamp from when the copy was performed.
To handle these errors, I've resorted to the following, mostly using PowerShell. I programmatically export all of my migration logs as CSV files. I programmatically filter the exported log files, to look for specific Error and Warning event types, and dump that subset of events into other files (FileErrors, SiteErrors, and OtherErrors). I manually review the CSV files to identify rows where fields like Warnings, Errors, or Details have exceeded reasonable limits and wrap for hundreds of lines (It would be great if export results were cleaner as well). I clean up that wrapped data for better readability. I re-migrate SiteErrors using the same scripts that were used for the initial site migration. I have a different set of scripts to re-migrate files that threw errors. There will also be some errors from re-migrating FileErrors that may require changes like limiting versions, but the number of errors that require manual intervention is significantly reduced. The OtherErrors are errors that need further review and may require manual migration. I have also used processes for handling Folder errors as well, but more often than not, I’ve found those to be reported inaccurately as a part of poor OneNote migration support. Of course, the errors which need to be addressed depends on which version of Sharegate you are running, and what has been changed in that version.
Using custom scripts and complicated processes on my end to handle Shargate shortcomings is less than ideal. Changes made in Sharegate application development can/will adversely affect my processes, which is why the Sharegate Desktop is the ideal location to be addressing the issues. If content migration reliability can’t be increased, than ease of addressing errors is of the upmost importance.