A primary determinant of whether a migration is a success or failure is based on the number of items that fail to migrate.
By default, this value is set to 1000. This means that a migration will be considered a success as long as less than 1000 items fail to migrate. Although this may seem generous, items fail for many reasons such as item corruption, misconfigured Destination servers, etc.
Even if items fail to migrate, you can always retry the failed items after the migration is complete.
We do not recommend decreasing this value, as your migration may fail often with valid errors causing migration downtime (as the migration will be halted until you resubmit the mailbox for migration). Additionally, some users hit the 1000-failure limit over and over again because the failed items really cannot be migrated, for which we recommend increasing this number.
The following are pros and cons of increasing/decreasing this limit:
Increase failure limits:
- Migration will fail less often, as we need to fail more items before failing the migration. For example, this is good if there are a lot of corrupt items that can never be migrated.
- Migration will take longer before it fails. For example, if the credentials are changed and we are no longer able to connect, the system may take significantly longer to fail the migration.
Decrease failure limits:
- Migration will fail sooner. For example, if you have email notifications enabled, and you want to be notified when a small number of errors are reached, this will allow the migration to fail more quickly.
- If the Project contains a lot of un-migratable items, you will get a lot of failures. Failing a migration causes migration downtime, as it will not continue until you resubmit it.
The default limits we set are optimal for 99% of all migrations. You should not change these values unless you're confident in knowing their use. We suggest contacting Support before changing them.