Handling errors during migration

When you see an error in the logs, it was caused by either the source or destination server.

The error messages that you see are either low level errors that are generated (like connection timeout, or host not reachable) or higher level errors (like system error, cannot be fetched). Usually the higher level errors are the cryptic ones. These are messages returned to us directly from the source or destination server.

When you see an error, you can click on them and see what the error means. We try to provide remedies on errors once we determine the exact cause. If we have not yet determined the exact cause, we suggest resolutions to similar errors that we have encountered.

There are 2 ways to handle errors: 1) do nothing and move on or 2) retry those items again.

In some cases, you may want to do nothing because a retry will result in the same problem. For example, we have encountered systems where we cannot export the item because it’s corrupt. No matter how many times you try, the source server will not give it to us and will error out. You don’t want to retry these because it’s pointless and just causes delays in your migrations (because we retry the message 3 times by default losing 15 minutes).

In other cases, the errors may have been caused by network upgrades, service updates to the server, or some other error that was caused by human intervention. In these cases, retrying will pick up those items that we missed. In order to accomplish this, you will need to:

1. Stop the migration if it’s currently happening
2. Select the advanced option do not resume from last migration from the connector (if you want to apply to all mailboxes) or directly on the mailbox.

3. Submit the mailbox for migration

Note that this setting only takes effect on submission of a migration. Changing this setting while a mailbox is being migrated will not apply.