Mailbox migrations vary 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.  

Supported Mailbox Types

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.

Create a Mailbox Migration Project

1. From MigrationWiz dashboard, click Go To My Projects.

2. Click Create Project.

3. Select a Mailbox migration type. 

4. Click Next Step.

5. Enter a project name and select a Customer from the list.

   1. If the customer hasn’t already been created, you can do so here.

   2. To create a new customer, click New, provide required details including primary email domain and company name, and click Save.

6. Click Next Step.

Migrated Items

Certain mailbox items are always migrated, regardless of source or destination. 

Special cases in email migrations

Hidden folders

If a system folder exists on both the source and the destination, MigrationWiz will detect it and migrate items to that location. For example, Exchange stores attachments in a hidden system folder called 'Files'. If the destination also has this folded, MigrationWiz will automatically migrate the items. As these are hidden, it may appear they did not migrate.

If the content needs to migrate to a different folder, use folder mapping to specify the new destination folder. 

Encrypted Content

We migrate MIME content in an as-is state. S/MIME messages can be migrated and will remain encrypted at the destination. Viewing them on the destination requires the same certificate used to encrypt them, including its corresponding private key. 

Messages with Azure Information Protection will be migrated, but will not be viewable at the destination, as the source tenant policies will not be available on the destination. To migrate in a viewable format, decrypt these messages on the source and migrate the decrypted emails. To encrypt them at the destination (this is optional), simply recreate the security policies on the destination and then reapply the policies to the migrated messages. Our data retention and security policies can be reviewed at our BitTitan Data Security and Privacy Policy page.

Color Categories

The default colors will be maintained during migration. However, if additional color categories have been defined at the Source, other than those supported at the destination, they will not be migrated. Instead, they will be converted to the default calendar color at the destination. For example, Google supports more calendar colors than Microsoft 365. Any calendar colors on Google that are not any of the six (6) default colors on Microsoft 365 (blue, orange, green, purple, red, yellow) will be converted to the default color on Microsoft 365 (light red).

Calendar meeting links

Lync, Skype or Teams events will be migrated but will usually not work in the destination because the links are for the source environment. These events will need to be recreated at the destination. There are exceptions to this rule, but they are not consistent.

Mailbox Migration FAQ

Licensing Large Items

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.

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, 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.

4. 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.

• By default, MigrationWiz will only migrate Mailbox Folder Permissions for System folders. To migrate permissions on folders that were created by users, the Advanced Option must be set toMustMigrateAllPermissions=1in your project.

  This setting is an option because it is not a best practice, and scanning for permissions will slow down the migration.

  We do not migrate any permissions for the Default or Anonymous user accounts.

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 Folder Filtering & Mapping.

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.

• 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:

• You can use the Change Domains button in MigrationWiz
• You can download and run the Change-MW_ExportAddresses and Change-MW_ImportAddresses PowerShell scripts attached at the bottom of this article. 

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 – Full 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. The pre-requisites and download link for the SDK can be found here: Install the BitTitan SDK
• Download the PowerShell script(s) required to make the bulk changes. Links for downloading the scripts can be found at the bottom of this KB: 
  • The Change-MW_ImportAddresses script changes all Destination addresses
  • The Change-MW_ExportAddresses script changes all Source addresses.

• 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 the project 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.
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

FolderMapping="^SourceFolder->DestinationFolder"

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

​​      3. Click on Save Options.

      4. Click on Save Project.