MigrationWiz will occasionally report failures, usually of individual mailboxes or items. This article covers the causes and remediation of those failures. There may be causes or results which are not covered here, or which require a new solution. Failures are not errors – specific errors can be researched in our Error Lookup section. If the information here is not solving your issue, contact Support and we will assist you with your problem.
If you have specific questions, use the anchor links to the left side of the page to navigate to your question.
To Re-Migrate Failed Items
MigrationWiz has a built-in method of retrying migrations for mailboxes that have failed due to errors without consuming more licenses. If you have a small number of errors, try this method first before attempting to solve additional errors.
Only failed items will be submitted for another migration attempt. Successful items will not be migrated again.
To retry errors:
- Sign into your MigrationWiz account.
- Click the Go To My Projects
- Select the project which contains errors.
- Checkmark the box next to the items you wish to retry.
- Click on the Start
- Select Retry Errors from the menu.
- Click the Retry Errors
Mailboxes will only successfully submit for remigration if the following is true:
- The last migration completed successfully.
- The mailbox contains at least one error.
If your mailbox does not satisfy these conditions, you will not be able to start the Retry Errors pass from the migration flyout window.
When errors are repaired, they will disappear from the error log. Some errors may not disappear if the Source item was not reprocessed (due to filters, for example), has been deleted or moved, or if the item failed again.
Find Subject of Failed Items
In order to comply with privacy policies and security regulations, we do not store the subject of any item by default. You can have us store and report the subject of failed items using an opt-in option if you wish.
If some items failed to migrate but you did not enable subject logging prior to the migration, nothing will be logged. Therefore, you may want to retry failed items after enabling this option. Failed items will be reprocessed and we will log their folder path (if available).
To enable subject logging of failed items for all mailboxes under a project:
- Sign in to your MigrationWiz account.
- Edit your Project.
- Open Advanced Options.
- Under Maintenance, checkmark the option Log subjects of failed items.
- Click on Save Options.
- If a mailbox is already running when you enable this option, you must restart the migration for the change to take effect. You may also need to retry failed items for subjects to be logged.
- To help identify offending items, mailbox statistics include a count of failed items per folder as well as an aggregate error size. A large error size typically indicates that some large items could not be transmitted due to size limits at the Source or Destination.
Failures due to Timeout
Your migration may complete with failed items. In most cases, failed items will only consist of a) corrupt items and/or b) large items. Large items may fail to migrate because of connection timeouts. A few of these scenarios are covered below.
My Destination system allows items up to ‘Y’ MB. Why did items which are only ‘X’ MB fail to migrate?
Email systems enforce many limits which change the way MigrationWiz processes timeouts. You could migrate to a system that has a 25MB receive limit, a 50MB send limit, but only a 10MB API create limit. MigrationWiz is subject to the API create limit, not the send or receive limit. This will cause timeout problems.
Also, most email systems have a connection timeout. Although the limit may be 25MB, the email system may close any open connection after (for example) ninety seconds, regardless of limits. Unless an item can be transmitted in under ninety seconds, the item will fail to migrate, with a timeout error.
All transmitted email data must be encoded, encrypted, or encapsulated, which may inflate the size without notification. For example, Base64 encoding is often used to encode email content. Base64 encoding alone can cause significant inflation, so the limit may be reached faster than expected.
I want all of my items to be migrated. What can I do about this?
Retry failed items as many times as you want. Additionally, if you have control over the email system, you could increase size and connection limits. However, some items may still fail due to corruption or other issues outlined elsewhere in this document.
Some items are still failing to migrate no matter how many times I try. What next?
If we are unable to migrate large items because of their size, you will need to handle them manually. For example, using Outlook, you can create a Search folder which identifies all items larger than ‘X’ MB across all folders. The method to identify and handle those items may differ depending on your Source and Destination systems. You may also want to enable logging of failed subjects.
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 fewer than 1000 items, per user, 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.
If you increase the limit:
- 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.
- However, the migration will take longer before it fails.
If you decrease the limit:
- 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 items which cannot be migrated, 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. If you would like to change them, we suggest contacting Support for assistance.
If a mailbox has a large number of failed items, migration speeds will be reduced because MigrationWiz will repeatedly attempt to retry migrating these corrupt items before logging them as an error.
In such circumstances, the following approach is recommended:
- Stop existing migrations.
- In project Advanced Options, select the check box labeled Do not retry errors.
- Increase the value for Maximum errors per migration to a very high number, such as 5000.
- The default value is set to 1000.
- Checkmark the box labeled Log subjects of failed items.
- Perform the migration.
- Once the migration completes, from your top-level project list dashboard, click on the pie chart icon. This will send an email to the SMTP email address that is registered to your BitTitan account.
- This CSV file will provide a detailed error list, with subject headings included.
Note: If those items are corrupted, they will never be able to be migrated with MigrationWiz. At this point, the best approach is to share this error list with the end user. If they are deemed to be important messages, you can either manually forward them to the Destination mailbox, or export-import them via a PST file (refer to http://blogs.technet.com/b/exchange/archive/2007/04/13/3401913.aspx for more information on these steps).