MigrationWiz - Failures & Error States

May 29, 2024 16:13

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.

View Errors

Sign in to your MigrationWiz account.
Open the Project where the mailbox resides and locate the specific mailbox.
For each item, click on the Status link. This will provide a description of the error as well as the steps to verify your configuration. Please carefully review all information and perform all steps.

Each error logged represents an item that was not migrated.

Re-Migrate Failed Items

Each error logged represents an item that was not migrated. MigrationWiz contains a mode in which you can resubmit the migration to retry failed items. This mode of operation is always free of charge. You may only submit items in this mode if they satisfy all of the following conditions:

The last migration was completed successfully.
The item contains at least one error.

If your item does not satisfy these conditions, you will receive a warning when submitting the migration in this mode and your request will not be fulfilled.

MigrationWiz has a built-in method of retrying migrations for items 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 that 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

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 the 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 before 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.

In many cases, we are unable to read the subject of a failed item. For example, if the item is corrupt, was deleted during migration, or because the item is very large (i.e., the connection timed out before the item could be read).

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 be completed 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 that change the way MigrationWiz processes timeouts. You could migrate to a system that has a 25MB receive limit, and 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, you could increase size and connection limits if you have control over the email system. 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 cannot migrate large items because of their size, you need to handle them manually. For example, you can use Outlook and create a Search folder that 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 the logging of failed subjects.

Failures Due to Advanced or Support Options

Several options can impact whether certain items in a mailbox get migrated. Make sure these options are not blocking the migration of items you tried to migrate.

Pass Submission

Upon submitting your items for a migration pass, these settings will filter items out:

Item type filtering (not migrating calendars, mail, contacts, etc).
Pre-stage migration (will not migrate Contacts or Calendars by default or any data newer than the specified date range).

Project Level

Check to see if you have one or more of the following enabled under Advanced Options:

Folder filtering.
Date filtering.

Item Level

Check to see if you have one or more of the following enabled under Advanced Options:

Folder filtering.
Item type filtering (not migrating calendars, mail, contacts, etc).

Failure Limits

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 completing the migration.

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 that 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 want to change them, we suggest you contact Support for assistance.

Failed Items

Consider that when a mailbox contains a large number of failed items the 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.
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 is completed, click the pie chart icon from your top-level project list dashboard. 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.

If those items are corrupted, they will never be migrated with MigrationWiz. At this point, the best approach is to share this error list with the end user. If they are 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).

Per Folder Success & Error Count

You can view the item success and error count per folder by performing the following:

Sign in to your MigrationWiz account.
Open the Project where the mailbox resides and locate the specific mailbox.
Click on the mailbox Status.

The Folder Summary will display successes and errors per folder.

Corrupt Items