MigrationWiz - Email Migrations - FAQ

Mailbox migrations very by source and destination, but have a few things in common. The most commonly asked general questions are below. For specific steps and guidance based on your migration scenario, see our migration guides. 

Mailboxes may be in use during a migration on both the source and destination. If items are removed or moved on the source during the migration, there may be errors or failures. We recommend notifying users to avoid changes to data during the migration process. 

Once your migration has been started and assigned to a migration server, it will cache the Mailbox and Project settings specified at the time the migration was started. This behavior is by design. Should you make changes to your Mailbox or Project after your migration started, you should stop and restart your migration.

MigrationWiz does not have any limitations on the mailbox size to migrate. We have migrated mailboxes that contain hundreds of gigabytes (GB) of data.

​​​E-mail that already exists in a Destination mailbox will not be changed or affected in any way during the migration process.  MigrationWiz will not delete, change, or move any items that exist in the Destination mailbox prior to running a migration.  

MigrationWiz Supports:

Encrypted Email: For all Source email systems, any email sent or received using third-party encryption plugins will not migrate using MigrationWiz. This email will need to be decrypted before it can be migrated.

Migration between different domain suffixes: You may migrate data between email accounts that have different domain suffixes.

Out of Office Messages: There are two ways to set Out Of Office messages in OWA. You can set an Out of Office for a user as an admin using MailTips, or you can set it as the user in the user's settings. Neither of these are migrated with MigrationWiz, because they are profile settings and not mailbox content.

Out Of Office (OOF) messages may be configured at the Destination to be automatically sent when the mailbox owner is on vacation, sick, or on an extended leave of absence. OOF messages will not be triggered when migrating mailbox data via Exchange Web Services (EWS), therefore it is not necessary to disable automatic replies during migration.​​

Folder Permissions: Folder permissions are migrated using the following approach:

  • First, MigrationWiz will try to match the source SMTP email address to the destination SMTP email address.
  • Next, MigrationWiz will try to match the source display name to the destination display name.
    If more than one match is found on the destination display name, a failure will occur and the permissions will not be assigned to that particular UserID.

Important: MigrationWiz migrates folder permissions but not delegate/sharing permissions, which means that "Send As" and "Send On Behalf Of" permissions are not migrated.

Pre-existing items: Email that already exists in a Destination mailbox will not be changed or affected in any way during the migration process.  MigrationWiz will not delete, change, or move any items that exist in the Destination mailbox prior to running a migration.  

S/MIME Email: MigrationWiz can migrate S/MIME digitally-signed messages with or without encryption.

Licensing Large Items

You are limited to 50GB of data transfer per license that you purchase.

If you have a mailbox requiring over 50GB of data transfer, and you have purchased a mailbox license, your migration will stop automatically after transferring 50GB.

However, you can restart the migration from where it left off by purchasing another mailbox license and resubmitting it for remigration.​

Shared Mailboxes

Shared mailboxes migrate in a similar way to a regular mailbox migration.

  • If migrating with administrative credentials: From the MigrationWiz dashboard, click on the Quick Add button, and enter the email address of the shared mailbox at the Source, and the email address of the shared mailbox at the Destination. When the migration is performed, it will migrate with the administrative credentials added when creating the project. The administrator account must have full access permissions to the shared mailbox in order to perform the migration. If performing a Bulk Add of users, simply include the shared mailboxes in the CSV file that is used to import the mailboxes into the MigrationWiz dashboard.
  • If migrating without administrative credentials: From the MigrationWiz dashboard, click on the Quick Add button, and enter the email address of the shared mailbox at the Source, and then the login name and password of either the owner of that shared mailbox or an account that has full access permissions to the shared mailbox. Also enter the email address of the shared mailbox at the Destination, and then the login name and password of either the owner of that shared mailbox or an account that has full access permissions to the shared mailbox.

The screen shot below using the fictitious acme.com provides an example of how to add the shared mailbox into the MigrationWiz dashboard, for the Destination.

migratesharedmailbox.png

The login name and password can only be added if the MigrationWiz project is created without administrative credentials.

Refer to the Create a shared mailbox article from Microsoft for more information about how to create and use shared mailboxes in Office 365.

As with a regular mailbox migration, it is necessary to purchase mailbox migration licenses or User Migration Bundle licenses in order to perform the migration.

Shared mailboxes make it easy for a specific group of people to monitor and send email from a common account, like public email addresses, such as info@mining88.com or contact@mining88.com. When a person in the group replies to a message sent to the shared mailbox, the email appears to be from the shared mailbox, not from the individual user.

Shared mailboxes are a great way to handle customer email queries because several people in an organization can share the responsibility of monitoring the mailbox and responding to queries. The customer queries get quicker answers, and related emails are all stored in one mailbox.

Shared mailboxes are also ideal for storing the mailbox contents of terminated employees.

It is not necessary to assign licenses to shared mailboxes in Office 365, except when they are over their storage quota of 50GB.

In the back end, shared mailboxes are identical to user mailboxes. Look at the user list; there will be a user created for the shared mailbox.

Mailbox Size

There is a relationship between mailbox size and data transferred but they can be quite different and cannot be compared directly.​ The size statistics shown on the mailbox statistics page indicates the amount of data transferred over the wire. This typically differs from your mailbox size (as reported by your Source email system) for different reasons including:

  • Size calculation: Your Source email system will calculate and report mailbox sizes using proprietary formulas/methods.
  • Content conversion: The same data may be encoded using different formats at the Destination (i.e., plain text + HTML MIME parts).
  • Protocol overhead: Data as read from the Source will often include protocol data such as headers, flags, IDs, etc.
  • Data encryption: Unless you configure your connection to use non-SSL endpoints, all data will be encrypted.
  • Data compression: Data may be compressed or decompressed during storage or transmission.
  • Data encoding: Many communication protocols will encode data (like Base64 encoding, SOAP encapsulation).

Also, some items may not have been migrated (details), or may have failed to migrate (up to the error count specified on your project).

If you are trying to compare mailbox sizes because you are looking for missing items, click here.

Add Mailbox to Existing Project

  1. Sign in to your Migratio​nWiz account.
  2. If you do not see your projects listed, click on the Projects​ section.
  3. Click on the name of your Project in the list. 
  4. Click on the Add button.​​

Sent Items migrated to Wrong Location

This article applies to mailboxes whose Source "Sent Items" folder was successfully migrated, but whose location at the Destination is different from the expected one.

The IMAP protocol only identifies the "Inbox" folder as a system folder. There is no clear identification of other system folders such as "Sent Items", "Deleted Items", etc.

For example, a "Sent Items" folder may be labeled as “Sent Items”, “My Sent Items”, “Sent”, “Sent emails”, “Courrier Envoye”, ”Sendte emails”, etc. There is no reliable way for us detect if a specific folder is a Sent Items folder. For this reason, we map folders by name.

​​However, we support folder remapping as an advanced feature. To implement specific folder mappings:

  1. Go to Advanced Options. To enter Advanced Options within the new MigrationWiz interface, select your project name, then click on Edit Project at the top left, then click on Advanced Options at the bottom right​.
  2. ​Within the Support Options section, specify the following:

FolderMapping="^SourceFolder->DestinationFolder"

Example: FolderMapping="^My Sent Emails->Sent Items"

​​      3. Click on Save Options.

  1. Click on Save Project.

The expressions on the left and the right are regular expressions.

Migrating Permissions

Folder permissions are migrated using the following approach:

  • First, MigrationWiz will try to match the source SMTP email address to the destination SMTP email address.
  • Next, MigrationWiz will try to match the source display name to the destination display name. If more than one match is found on the destination display name, a failure will occur and the permissions will not be assigned to that particular UserID.

Important: MigrationWiz migrates folder permissions but not delegate/sharing permissions, which means that "Send As" and "Send On Behalf Of" permissions are not migrated.

Merging Mailboxes

If you intend to merge several email accounts that you have been managing separately into a single email account, you will be able to do it via MigrationWiz, by migrating all Source mailboxes at the Destination where they will be mixed. You will need to purchase as many licenses as Source mailboxes you want to merge.​

You will need to perform the following steps:

  1. Create a Project, and add a mailbox to migrate from the first Source mailbox to the single Destination mailbox.
  2. Submit the migration from the first mailbox to the Destination mailbox.
  3. Wait until the migration has completed.
  4. Add a mailbox to migrate from the second mailbox to the same Destination one.
  5. Open Advanced Options.
  6. Under Support, checkmark the Do not search destination for duplicates button.
  7. Submit to migrate from the second mailbox to the single Destination mailbox.
  8. Wait for completion.
  9. If you have more than two accounts, repeat Steps 4 through 8.

This will require two or more licenses (one for each Source mailbox).

If you h​ave duplicate email messages across Source mailboxes, you will encounter duplicate ones at the Destination mailbox.

You can also migrate the Source mailboxes into individual subfolders at the Destination as described in the next section. 

Migrate Mailbox to Single Subfolder

It is possible to migrate a Source mailbox into a single subfolder of a Destination mailbox, but contact and calendar folders will need to reside under the root contacts and calendar folders.

These folder mapping support options ensure the folders are created at the correct location:

First:

FolderMapping="^(?!Calendar$|Calendar/|Contacts$|Contacts/)->DestinationFolder/"

Second:

FolderMapping="^((Calendar)([/]?)|(Contacts)([/]?))->$2$4/DestinationFolder$3$5"

The support options above both need to be added in the Advanced Options for your project or for individual mailboxes.

To add for a single mailbox, click on the pencil icon to the far right side of the email address that you wish to edit.  

Replace "DestinationFolder" with the name of the folder you want to use at the Destination.

Important: The folder mapping support options listed above must be added in the order shown. If they are not added in this order, some contents of the migrating mailbox may become invisible and inaccessible on the destination

The spelling of both 'Calendar' and 'Contacts' must also reflect the language of the folder name at the Destination mailbox, e.g., 'Calendar' will be 'Calendrier' in French and 'Contacts' will 'Contactpersonen' in Dutch.

Migrating Suggested Contacts and Autocomplete Lists

It is important to understand the difference between Autocomplete Lists and Suggested Contacts.

Autocomplete Lists

When email addresses are typed in, Outlook remembers them and can offer autocompletion when adding recipients to a new email message. The Autocomplete List stores email addresses in a server-side hidden file. Therefore, those contacts remain accessible when a user has multiple computers running Outlook 2010 or later.

If you are using the DeploymentPro product to automate the configuration of Outlook profiles, Autocomplete Lists will be migrated over to the new profile, as part of the process. The DeploymentPro Guide provides more information on the steps to follow to run DeploymentPro projects. If you are using DeploymentPro, you will not have to manually migrate these.

Suggested Contacts

Suggested Contacts is a special contact folder introduced with Exchange 2010 and was removed in Exchange 2013. This folder creates contacts for each new address a user sends email to.

Summary

This table shows which type of contacts are supported by Outlook/Exchange, depending on the version.

Type

2010

2013

Autocomplete List (mailbox data)

 x 

 x 

Suggested Contacts

 x 

 ​​

  • Autocomplete Lists:
    • From Exchange Server 2003 / 2007 (.Nk2 file): MigrationWiz will not migrate these. This process must be done manually.
    • From Exchange Server 2010 / 2013 / 2016 (server-side file): MigrationWiz will not migrate these. The DeploymentPro product will migrate these. If you are not using DeploymentPro, the process must be completed manually.
  • Suggested Contacts:
    • From Exchange Server 2003 / 2007 / 2013 / 2016: Not applicable.
    • From Exchange Server 2010: Will be migrated by MigrationWiz.

Autocomplete Lists and Suggested Contacts cannot be migrated if the Source Exchange server is unavailable.

Finding Large Items 

It is possible that the size item limit on the Destination is lower than the Source. This will result in migration failures for those items that are larger than the limit on the Destination.

Before you start a migration, it is possible to identify the items that will fail to migrate by doing a mailbox search for large items on the Source.

  • This is an end user approach, which requires each end user to perform these steps. 
  • This article includes instructions for Outlook clients and G Suite webmail clients. Refer to the option that matches your client.

Option 1: Using Outlook Client

  1. Create a new search folder.
  2. In the resulting drop-down list, scroll down and select Large mail, and click on Choose...
  3. Change the number to the item size limit on the Destination (e.g., 25000), and click OK twice.

You will now have a new folder, under Search Folders, that will display all the emails that are larger than the selected size.

Option 2: Using G Suite webmail client

  1. Access the G Suite Gmail website.
  2. On the Search box, type the item size limit on the Destination (e.g., 25000000) and click on the search icon.

The value entered in the search box must be in Bytes.

Bulk Name Change

Domain Name

There are two ways you can bulk update the domain name in the email addresses of migration mailboxes:

Why might it be necessary to change the Source or Destination address of all your Users on a MigrationWiz Project?

  • If you are performing a tenant to tenant migration while keeping the same domain name, and you started the migration using the vanity domain on the Source addresses, we recommend using .onmicrosoft.com addresses for both Source and Destination addresses to avoid this.
  • If you just ran Autodiscover on MigrationWiz to discover all your Source mailboxes, and you are migrating into a different Destination email domain.

These examples are two among others that might make it necessary to have to change those addresses.

Use the Change Domains button

MigrationWiz now provides the option of doing a bulk update of email addresses on both the Source and Destination computers, where the change is of the address domain. The image below shows the Change Domains button.

When you click on the Change Domains button, the following box opens to allow you to bulk change the domain associated with mailboxes on the Source or Destination.

Bulk Name Change – All Addresses 

Use the BitTitan SDK PowerShell script

  • If the BitTitan SDK is not installed on your computer, the first step will be to download and install it. Our SDK will include the PowerShell and the Management Console modules.
  • Download the PowerShell script(s) required to make the bulk changes:
  • Both scripts make changes based on a CSV file, that needs two columns, as shown below:
  • It's important that you name column A as "UserPrincipalName" and column B as "NewUPN", because those are the names hard-coded in the script.
    • List all the current addresses in column A.
    • List all the new addresses, with the new domain name, in column B.

      You can obtain those addresses by exporting them via PowerShell when connected to the Source or Destination system (i.e., via the On-Premises Exchange or the Exchange Online PowerShell).

Follow these steps to run the PowerShell scripts:

  1. Once you run the script, the first thing it will do is prompt you to enter your MigrationWiz credentials as shown below.
  2. After entering your credentials, the script will prompt you to enter the MigrationWiz project name, and the location of your CSV file.
  3. Once all the data is inserted, the script runs, and changes all the Source or Destination addresses, as defined in the CSV file.

"Sent Items" folder. 

This information applies to mailboxes whose Source "Sent Items" folder was successfully migrated, but whose location at the Destination is different from the expected one.

The IMAP protocol only identifies the "Inbox" folder as a system folder. There is no clear identification of other system folders such as "Sent Items", "Deleted Items", etc.

For example, a "Sent Items" folder may be labeled as “Sent Items”, “My Sent Items”, “Sent”, “Sent emails”, “Courrier Envoye”, ”Sendte emails”, etc. There is no reliable way for us detect if a specific folder is a Sent Items folder. For this reason, we map folders by name.

​​However, we support folder remapping as an advanced feature. To implement specific folder mappings:
  1. Go to Advanced Options. To enter Advanced Options within the new MigrationWiz interface, select your project name, then click on Edit Project at the top left, then click on Advanced Options at the bottom right​.
  2. ​Within the Support Options section, specify the following:

FolderMapping="^SourceFolder->DestinationFolder"

Example: FolderMapping="^My Sent Emails->Sent Items"

​​      3. Click on Save Options.

      4. Click on Save Project.

The expressions on the left and the right are regular expressions.

Changing MX Records During Migration

MigrationWiz uses the information you specify on your Project (host name, URL, etc.), in conjunction with email addresses or other credentials, to connect to Source and Destination items. We do not use MX record information in order to connect to Source and Destination items. The MX record for your d​omain may point to the Source or Destination system. MX record information controls where email gets delivered, but we never use MX record information to log in to the Source, or the Destination.

Only incorrectly changing A records may affect the URL or host name you specify on your Project. If you need to update A records in DNS, note that we accept URLs and host names in IP format.

Calendars 

Recurring appointments

In some cases, you may find a migrated recurring series with a yearly recurrence when the Source used a different recurrence pattern (for example, every two weeks). This is incorrect, but done as a way to address limitations of the Source system.

​This happens when migrating from Source systems that do not return the recurrence pattern via their API. Instead, those Source systems return individual (expanded) recurring appointments. For example, if the recurrence pattern is every two days, the Source system may return:

Instance #1 - 6 PM on January 1st 2014
Instance #2 - 6 PM on January 3rd 2014
... more instances (some customized, some not) ...
Instance #50 - 9 PM on August 1st 2014 (customized instance)

In those cases, we do not have access to the recurrence pattern from the Source system, and so set a default recurrence (yearly recurrence). We then make each instance part of the same series and position it at the correct time. Even though the recurrence pattern is incorrect, all instances are positioned correctly and the recurring series can be manage​d as a whole (i.e., can cancel the entire series instead of having to manage each instance separately).

Suppressing calendar reminders

When a calendar item has a reminder on it, we will migrate the calendar item, and also its reminder settings. When a reminder is dismissed, the fact that it was dismissed may be stored locally on the email client. For example, Gmail/G Suite does not store whether an appointment has been dismissed or not on the server.

Therefore, when items are migrated from the Source mail system to a new Destination mailbox, previously dismissed reminders may be reactivated. In most cases, a one-click action is sufficient to dismiss all reminders. However, OWA may struggle to dismiss thousands of reminders and "hang". To suppress reminders for old appointments, before migration, set the following Advanced Option: SuppressReminderDays=X

Steps:

  • Click on Edit Project.​​
  • Click on Advanced Options.
  • In Support Only options, set: SuppressReminderDays=X
    • The value of X must be between 1 and 365 (inclusive).
    • Setting a value of X will mean that appointments whose end date is before [date of migration - X days] will have their reminders suppressed. 
    • Advanced Options are case-sensitive. The entry should be entered exactly as above (but change the "X" to a numerical value).

Archive Migrations

A note on root migrations

Exchange migrations do not migrate from the root, as EWS only sees and migrates items contained in folders. To migrate items at the root, create a folder for these items, drag and drop the items into the folder, and then migrate as usual. 

Mailbox and archive migration options

  1. Perform a standard mailbox to mailbox migration

    This is considered a mailbox migration project.

    Leave the Advanced Options at their default options, i.e., "migrate to mailbox" for Source and "migrate to mailbox" for Destination. When migrating, you specify the Source and the Destination mailboxes.
    Note: Once migration is complete, you could set Office 365 archiving rules so that mail will be moved to the archive mailbox, but that will all occur post-migration.

  2. Perform a mailbox to archive migration
    We support migrating directly to an archive mailbox. In this case, you would enter Advanced Options for your project and select archives as the Destination, as in screen shot below. You would then save these settings and run your migration following normal procedure.

    This would still be considered a mailbox migration. Therefore you would create a mailbox migration project and purchase mailbox migration licenses or User Migration Bundle licenses.

  3. Perform an in-place archive to mailbox migration

    In this case, when you create a project, you choose an in-place archive migration project.

    In this case, you would leave the Advanced Options at their default destination setting, "migrate to mailbox".
    This requires User Migration Bundle licenses.

     
  4. Perform an archive to archive migration

    This is also considered an archive migration project.

    In this case, you would change the Advanced Option for Destination to be "Migrate to: Archive."
    This requires archive licenses, rather than mailbox migration licenses.

     
Was this article helpful?
0 out of 0 found this helpful