When performing any migration, it is important to identify and realize that some items may not be migrated successfully. Large migration projects may include the migration of millions of items, and for a number of reasons, some those items may not reach their final target. The number of failed items in a migration project is frequently a fraction of a percent of the total number of items processed by the migration solution.
Below is a list of commonly identified reasons that items may fail to migrate successfully using Archive Shuttle (AS):
- Requests timing out.
- Items too large.
- Throttling denials.
- Target unavailability.
- Item unavailable or corrupt in the source.
- Unsupported items by the target due to size, type, or other properties.
As items can fail for any number of reasons, it is important to be able to account for the failures of a migration. During a migration, items may fail to migrate due to a dependency of the migration utility and not the utility itself. These types of failures are frequently logged through a migration utility despite the failure being independent of the solution.
Archive Shuttle retries all failures 10 times prior to marking it as a permanently failed item. Unless corrective action or temporary outage has taken place since the items were initially processed, it may be unnecessary to reprocess specific failures. Additionally, Archive Shuttle provides the ability to view the details of failed items within the user interface.
Should you wish to reprocess and log failed items in Archive Shuttle to get more information related to a failure, the following general process can be utilized:
1. Enable trace level logging on the appropriate module
2. Retry the item from the Failed Item screen, or Stage 1 Screen.
3. Capture and review the log file generated.
4. If possible obtain sample items that fail. (This is easier with import failures, as the items will exist in the Staging Area)
Depending on the size of your migration, it may not be reasonable to review all items which fail to migrate. It is suggested in instances where the volume of failures is high, but the overall percentage of failed items is low to review a random sampling of failed items for best results considering resource constraints.
Should you have questions or concerns related to any of the failures discovered, please prepare logging collected from a re-ingestion using the instructions above and start a ticket related to any single failure that was identified as a concern by emailing email@example.com