Microsoft 365 Mailbox Migration FAQ

This article covers general Microsoft 365 migration questions, as well as more specific information and troubleshooting for steps such as coexistence, impersonation, and litigation holds.

This guide is intended to be used in conjunction with the proper scenario-specific migration guide. 

Maximum file size

The maximum file size for migration through MigrationWiz varies by migration type and environment, but may never exceed 60GB

Private Chats

MigrationWiz no longer supports Teams' private chat history as part of Mailbox migrations due to Microsoft's restriction on Teams data access through EWS. For more information please review this article.


Settings for specific migration scenarios will be explained in the migration guides for your scenario. Some settings, however, may apply to multiple migration scenarios or require more explanation. 

Destination mailbox language

Destination mailbox language sets the language for system folder names in Outlook Web Access (OWA), but only in the case where a user or admin has never previously logged into the mailbox.

Do not utilize the MigrationWiz advance option to configure the Mailbox language setting. The destination mailbox language should be configured with the following methods:

Set msExchMailbox GUID attribute to null

This can be set within the Synchronization Rules Editor.

  • This is not supported if you have performed a directory synchronization using DirSync.
  • It is supported if performing a directory synchronization using ME-ID Sync, or ME-ID Connect.


  1. Run the Synchronization Rules Editor as an administrator. 
  2. Click In from AD - User Exchange to edit the Inbound Rule Type.  Coexist_4.jpg
  3. Select Transformations.
  4. Find the msExchMailboxGuid attribute. 
  5. Change it to the following: Expression - msExchMailboxGuid - NULL - Checkmark Apply Once
  6. click Update.
  7. Next, enable ME-IDSync or ME-ID Connect and perform a full synchronization. 

Now users may be assigned an Exchange Online license, and MigrationWiz may be used to migrate their mailboxes to Microsoft 365.

Access & Credentials

There are multiple ways to manage credentials in Microsoft 365 migrations. Certain migrations call for specific credential management options, which will be specified within the migration guide. This section offers more information and context for those options. 

Modern Authentication

BitTitan now supports Modern Authentication for Microsoft 365 endpoints used for Mailbox migrations. Modern Authentication provides a more secure authentication mechanism for registered applications to connect to Microsoft Entra and Microsoft 365. For more information on Modern Authentication, see this page from Microsoft: How to authenticate an EWS application by using OAuth.


  • A Global Administrator account with access to Microsoft Entra. MFA/2FA is not supported at this time. The administrator account will need to be excluded from these policies if enabled. 
  • MigrationWiz® Mailbox project(s) created and ready for configuration.
  • The application will require administrator consent
  • For OneDrive/SharePoint migrations: The Administrator account will require access to legacy authentication to retrieve the Site URL. For this reason, the administrator account will need to be excluded from any baseline security policies or have Conditional Access granted using a Conditional Access Policy


    The Administrator account will need to be added to the Exclude option.

Registration and Configuration

To register and configure your source and destination tenant please refer to the Obtain Client and Tenant ID Settings for Mailbox and Exchange Online Migrations section of the Authentication Methods Migrations KB.

Once you created a MigrationWiz project, do not forget to use the credentials you use here. These are required when setting up your endpoints (source and destination).

Destintation Settings.png

Please consider that you will not be able to save your project if you do not complete these fields, the credentials (client or tenant) are incorrect, or the credentials do not belong to the tenant. Once the information has been provided for both, the source and/or destination endpoint, and the customer selects Save and Go to Summary, MigrationWiz performs an endpoint validation check.

This validation tests the administrator credentials entered into the project and the Modern Authentication setup only. If there is an issue, the screen redirects to the endpoint and provides an error message or flyout that can be selected for more information regarding the error.

Common Errors when Configuring Your Endpoint

For more information, review the AADSTS700016, AADSTS90002, and ADDSTS50126 issues on the Common Errors Using Modern Authentication page.

Application and Directory ID Issues Administration Credentials Issues

Make sure to complete the Application (client) ID and the Directory (tenant)  ID fields, otherwise, the following warnings arise and you cannot go to the next step.

Application and Directory ID issues.png

This happens when configuring the source or destination endpoints.

Invalid Application Client ID at Source Settings

Check that the Application ID has been installed before or make sure that it is the right one. For more information, refer to AADSTS700016.

Invalid Directory Tenant ID at Source Settings

Check that the Directory Tenant ID has been installed before or make sure that it is the right one. For more information, refer to AADSTS90002.

Verifying Mailbox Access

Perform the following steps to verify mailbox access.

  1. Browse to
  2. Log in as admin email address.
  3. Enter the same password as specified in MigrationWiz.
  4. Enter the Admin portal.
  5. Click Users, then Active Users.
  6. Search for users entered in MigrationWiz to make sure the admin email address and the end user´s email address specified in MigrationWiz are not misspelled by searching for them.
  7. Make sure all users have licenses assigned to them (see here if using F1 Microsoft 365 licenses). All mailboxes on the Source system are created as mail users in Microsoft 365. When you assign a license to the mail user, it will become a mailbox user. We need a mailbox at the Destination to be able to migrate data.
  8. If you are not using impersonation, make sure the admin account has a license assigned to it. This can even be a temporary trial license.
  9. If you deleted and recreated users, make sure the users have been hard-deleted from the Deleted Users tab in the Microsoft 365 portal:

You must first use PowerShell to execute a hard delete. If not already installed, download and install the Azure Active Directory v2 PowerShell module.

Execute these PowerShell commands:

Import-Module -Name MSOnline

$LiveCred = Get-Credential

Connect-MsolService -Credential $LiveCred

Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin –Force

  • The PowerShell commands remove deleted users from the recycle bin and permanently delete them.
  • Click the Outlook tab to open the OWA and make sure you can open the end user´s email address.
  • After creating a user, you may experience small replication delays in Microsoft 365.
  • When you submit the project for migration, we try to automatically grant the administrator account permission on mailboxes (using impersonation), by executing Microsoft 365 PowerShell commands. In some cases, the Microsoft 365 PowerShell command may fail. If done manually, the issue should be resolved. The article, Impersonation and Delegation explains how to enable impersonation.
  • When migrating more than 10 mailboxes, you may experience throttling if not using impersonation. We recommend enabling impersonation; but keep in mind that if you enable impersonation, by default the administrator account does not have permission to impersonate user accounts. We attempt to grant impersonation rights behind the scenes, but it takes a very long time and can time out. You can either:

Shared Mailboxes

Shared mailboxes migrate similarly 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 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, 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 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 Microsoft 365.

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

Shared mailboxes make it easy for a specific group of people to monitor and send emails from a common account, like public email addresses, such as or 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 Microsoft 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.

Increasing the Administrator Credentials During the Source Endpoint Creation For Google Groups to Microsoft 365 Shared Mailbox Migrations

Increase the administrator credentials and avoid exported messages as individual emails instead of their original conversation thread format by using one of these options:

  • Use the UseMultiAdmin=1 advanced option.
  • Set the “Advance Option>Performance>Maximum number of concurrent migrations” to 3.
  • Create multiple projects to accommodate all the line items.


MigrationWiz leverages PowerShell to migrate the project line items, hence, there is an inherited PowerShell concurrency limitation of 3 line items per run. Selecting more than 3 line items may result in a timeout error.

Migrating permissions for user-created folders

By default, MigrationWiz will only migrate Mailbox Folder Permissions for System folders. Migrate permissions on folders created by users by setting the MustMigrateAllPermissions=1 advanced option in your project.

This setting is an option because it is not a best practice, and scanning for the permissions will slow down the migration.
We do not migrate any permissions for the Default or Anonymous user accounts.

Microsoft 365 FI (Formerly Kiosk) Users

To migrate to kiosk users, the migration project will need to be configured to use an admin account with impersonation rights. This allows us to bypass the limitations of kiosk users, who cannot connect directly via EWS.

To ensure that your migration project is correctly configured to migrate to kiosk users, perform the following steps:

  • Specify admin credentials
    1. Sign in to your MigrationWiz account.
    2. Click the Go To My Projects button.
    3. Select the project that needs to be modified.
    4. Click the Edit Project button.
    5. Click Edit Project from the drop-down menu.
    6. Select Destination Settings.
    7. Checkmark Use Admin Credentials and enter these.
    8. Click the Save Project button.
  • Enable Impersonation
    1. ​Click the Edit Project button.
    2. Click Advanced Options from the drop-down menu.
    3. Under the section title Destination: Microsoft Office 365, checkmark Use impersonation to authenticate.
    4. Click the Save button.

The admin account specified does not require a license and does not need to have other admin rights configured.


Impersonation in Microsoft 365

MigrationWiz uses delegation by default to log in to individual user mailboxes using administrative credentials specified on the connector. However, MigrationWiz also supports impersonation in specific environments.

Using impersonation:

  • Eliminates most "Connection did not succeed" errors.
  • Allows migration of more mailboxes concurrently.
  • Reduces the impact of throttling and connection limits.
  • Uses an administrator account without assigning a license to it.


To migrate using impersonation:

  1. Use admin credentials at the Destination.
  2. Sign in to the MigrationWiz account.​
  3. Edit the Project and click Advanced Options.
  4. If migrating from Microsoft 365, under Source, check Use impersonation to authenticate.
  5. If migrating to Microsoft 365, under Destination, check Use impersonation to authenticate.
  6. Click Save Options.

MigrationWiz will automatically run a remote PowerShell command to allow the admin account to log in to (impersonate) user mailboxes.

Here is the remote PowerShell command we execute when a mailbox has been submitted for migration:

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>

You may also run these commands manually. This is useful if there are delays from Microsoft and the Powershell command does not run immediately.

Exchange 2010+

MigrationWiz uses delegation by default to log in to individual user mailboxes using administrative credentials specified on the connector. However, MigrationWiz also supports impersonation in specific environments.


Using impersonation, sharing the throttling quota and connection limits associated with a single administrative account stops. Instead, the throttling quota of each user is used for each user's mailbox.

Using impersonation:

  • Eliminates most "Connection did not succeed" errors.
  • Allows migration of more mailboxes concurrently.
  • Reduces the impact of throttling and connection limits.


  1. Use admin credentials at the Destination.
  2. Sign in to the MigrationWiz account.
  3. Edit the Project and click Advanced Options.
  4. Under Destination, check Use impersonation to authenticate.
  5. If migrating from Exchange 2010+, under Source, check Use impersonation to authenticate.
  6. If migrating to Exchange 2010+, under Destination, check Use impersonation to authenticate.
  7. Click Save Options.

For Exchange migrations, to enable the admin account to impersonate users, run this PowerShell command:

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>

More information about this PowerShell command can be found here.

Office 365 plans named "Business Essential" and "Business Premium" do support impersonation. Follow the steps above, under the Microsoft 365 section, to enable support for the use of impersonation when migrating from or to "Business Essential" or "Business Premium".

If the above Advanced Options are set to use impersonation on a project, these settings will only become effective for those migrations that are started after saving the settings. Migrations that are already running will be unaffected by any such changes.

Synchronizing Microsoft Entra ID 

The recommended approach is as follows:

Use this article from Microsoft for the most up-to-date information: Set up Directory Synchronization

  1. Download and install ME-ID Sync or ME-ID Connect (if you need support for federation).
  2. Set msExchMailbxoGuid to Null.
  3. Configure filtering to define which objects are synced. Read the Microsoft Entra Connect Sync: Configure filtering article from Microsoft for more information.
  4. Use Microsoft AAD Sync or AAD Connect to create and synchronize the accounts from the On-premises environment to Microsoft 365.
  5. Assign Microsoft 365 licenses to accounts on Microsoft 365.
  6. Remove the null attribute from the msExchMailboxGuid, using the Synchronization Rules Editor.
  7. Perform another synchronization, using AAD Connect (or AAD Sync).
  8. Migrate, using MigrationWiz. This step can also be initiated after Step 4, once the licenses have been assigned.

If the local Active Directory (AD) schema has not been extended to support Exchange, then the steps above to set msExchGuid attribute to null are not needed. Synchronization can be run in the normal manner.

If you have previously used DirSync from an environment where the local AD supports Exchange, you cannot set the msExchangeMailboxGUID to null, because DirSync does not support this. Therefore, we recommend that you instead use AAD Sync or AAD Connect to rectify this problem, by following the steps outlined above.

If you do not set the msExchMailboxGuid to null, before running a synchronization from an environment where the local AD supports Exchange, all of the On-Premises Exchange attributes for each user will be synchronized, including the MailboxGuid attribute. If users are created in this state on Microsoft 365, an Exchange Online license cannot be activated unless Mailbox Replication Services (MRS) is used to perform the mailbox move or the steps above are followed to rectify this problem.

Once the users have been created on Microsoft 365, and the licenses have been activated, then you can start using DirSync, AAD Sync, or AAD Connect in the normal manner. The problem is limited to the user creation and license enablement (when the local AD supports Exchange).

If the mailboxes are on an Exchange Server in the local AD, Microsoft 365 accounts can be created using one of the following methodologies. 

  • ME-ID Sync or ME-ID Connect. Follow the instructions detailed in the recommended approach above.

  • Manually, one at a time.

  • By bulk import, via CSV file.

Licenses will also need to be assigned to the users, once they have been created.

Mail Routing

When Migrating Users in Batches

When migrating to Microsoft 365 using MigrationWiz, mailboxes need to be provisioned on Microsoft 365 to be able to write the content, mail, contacts, calendar, etc. (the user must exist on Microsoft 365 with an O365 license assigned to it, including a mailbox).

When a migration is performed in stages or batches, care must be taken to ensure that full mail flow continues for those migrated users.

This can be further explained by way of an example:

  • John and Tom need to be migrated to Microsoft 365. They are in different user batches. Batch 1 will be migrated first. Batch 2 will be migrated second.
  • John is in the first batch, gets migrated, and is using his Microsoft 365 mailbox.
  • Tom is in the second batch. This batch of users will be migrated at a later date.
  • When it comes to migrating users in Batch 2, these users will need to be activated on Microsoft 365 before migration since, as explained above, the mailbox needs to be active for MigrationWiz to migrate data into it.

What will happen if mail is sent to this newly activated Microsoft 365 mailbox while the migration is occurring?

If John sends an email to Tom, Microsoft 365 will internally route it to the new mailbox instead of the on-premises mailbox that Tom still uses. The email will not get lost since the email is stored in a mailbox that eventually Tom will get, but Tom will not have access to the email until the migration is completed.

How do we fix this?
The default mail routing can be manipulated by a mechanism called Criteria-Based Routing (CBR). Instead of dropping the mail in the mailbox on Microsoft 365, we can intercept the message and transfer it to the on-premises mail system, to be handled there. The interception is based on criteria similar to the membership of a specific Distribution List.

This is best explained by using the same example scenario:

  • John was migrated to Microsoft 365 in the first batch.
  • Tom is part of a Distribution List (DL) called NotMigrated.
  • We have set up a CBR mechanism that defines the following:
    • If you are a part of the DL NotMigrated, your mail will be intercepted and will be sent to the on-premises environment.
  • This way, when John sends an email to Tom, it will not go into the Microsoft 365 mailbox, but instead, be transferred to the On-Premises Exchange 2010+ environment.

Step-by-step setup:
For the setup, use PowerShell, because it is faster and easier to set up than working through the Microsoft 365 admin portal. If you need information about how to do this through the Microsoft 365 admin portal, contact Microsoft Support.

  1. Connect to Exchange Online PowerShell.
  2. Create the Distribution List (DL):
    New-DistributionGroup -Name "BtNotMigratedUsers"
  3. Add All Users to this DL.
  4. Create the Connector:
    $result = New-OutboundConnector -Name "CBRConnector" -ConnectorType OnPremises -SmartHosts "<fill smart host to source environment>" -UseMXRecord $false -IsTransportRuleScoped $true
    • -SmartHosts entry needs to be set to the URL or IP Address of the Source environment server.
    • On Exchange 2003, 2007, and 2010, this will be the address of the Transport server.
    • On Exchange 2013 and 2016, this will be the address of the Mailbox server, not the Transport server.
    • If the Source environment is Hosted, you would need to obtain this address from the Hosted Provider.
    • If the Source environment is G Suite, you would need to change the -SmartHosts entry to be the following: 
      •  -SmartHosts “”
  5. Create Rule:
    $result = New-TransportRule -Name "PilotInABoxRule" -SentToMemberOf "BtNotMigratedUsers" -RouteMessageOutboundConnector "CBRConnector"

When a user is fully migrated, remove the user from the DL, and they will receive their email in their own Microsoft 365 mailbox.

There must be a mail-enabled contact on-premises for each user that has been migrated.


Setting up Coexistence in Tenant to Tenant Projects

Microsoft 365 Tenant to Tenant Coexistence provides coexistence functionality for Microsoft 365 to Microsoft 365 migrations. When performing a Microsoft 365 migration and cutover is planned for a later date, migrations are done in batches. These migration types generally require coexistence so that the users on the source and destination can seamlessly communicate. This feature enables migrated users to be able to see the non-migrated users' free/busy status and their contact details.  

Migration can be completed in batches, but all the users need to be in the same project. Once a project is set up, users can only be added or removed from the source environment, then use the Rediscover Items button in MigrationWiz to sync those changes. Users cannot be manually added or removed from the migration project.


Microsoft 365 Tenant to Tenant migrations with Coexistence only support migration scenarios where the domain name is changing between the source and destination.  Migrating and keeping the same domain name is not supported at this time.


Microsoft Entra Connect cannot be used to do anything with the destination user accounts until after the migration project is fully completed.

Setting up the Microsoft 365 Tenant to Tenant Coexistence

  1. Launch MigrationWiz and create a Mailbox project. For help creating a new Mailbox Migration project, see MigrationWiz Projects.
  2. Set up the Source and Destination endpoints as Microsoft 365. 
  3. Enable Tenant to Tenant Coexistence by selecting the checkbox during the initial project creation.
  4. Configure the Tenant to Tenant options.
    • Configure Domain Addresses: Enter the primary Source and Destination vanity domain names. The Source domain is optional and can be left blank. This will enable coexistence for all domains on the Source.
    • Setting Global Administrator Credentials: A Global Administrator account is required on both the Source and Destination endpoints. 


      The destination tenant Administrator account needs to be able to access MSOnline, so the account must use the domain to ensure the correct access levels.
    • Choose Microsoft 365 License: Select the Microsoft 365 License type to be used on the Destination.  When the mail-enabled contact is converted to a user account with a mailbox, this is the license that will be applied.
    • Migrate Distribution List and Groups: Select the groups that are to be included as part of this migration.  Changes to the Distribution Lists and Groups can be synced during the project. 
  5. Click Save and Go to Summary.

Distribution List Changes

It is possible to sync changes to the Distribution Lists before a migration by using these steps:

  1. Make your changes to the Distribution lists or groups in the Source Environment.
  2. Click Tenant to Tenant Management.
  3. Select Sync Distribution List.

Tenant to Tenant Migrations with Coexistence 

User Migration Bundle licenses are required for this migration. Only specific Microsoft 365 licenses are supported for this migration. The supported types are listed in the Migration Setup drop-down menu. Only one Microsoft 365 license type can be used per project and the Microsoft 365 license types cannot be changed once the project has been set up.

The migration can be completed in batches; however, all the users need to be in the same project.

Once a project is set up, you can use the Rediscover Items option in the Manage Tenant to Tenant menu to add/remove users from the project. The users must be removed or added to the Source environment before the Rediscover is used. Cloud accounts are created on the destination. User passwords will be created as part of the DeploymentPro Profile Configuration.

Microsoft Entra Connect cannot be used to do anything with the destination user accounts until after the migration project is fully completed.

Once the Tenant to Tenant Coexistence option is selected and the migration is saved, the coexistence option cannot be removed. It is recommended to make sure that the scope and time frame of the migration is known ahead of time.

A Global Administrator account is required for both the source and destination endpoints. If one is not available to be used, then this migration type cannot be used.

All users on the source will be discovered to create mail-enabled contacts for those items on the destination. This migration type, therefore, is unsuitable for part divestitures from the source tenant. The mail-enabled contacts will be converted into cloud-only user mailboxes. Synchronization with on-premises objects with AADC cannot be performed until after the migration.

Only a single-target domain is supported.

A Tenant to Tenant Migration with a Coexistence project is unique in MigrationWiz.  While the overall process is no different from any other migrations, this specific type of migration does the extra setup to establish the coexistence link between the Source and Destination tenants.

After following the steps in the Microsoft 365 Tenant to Tenant Coexistence Project Setup Guide above, MigrationWiz will perform several actions in the background on both the source and destination to prepare the users for coexistence. This process is done automatically, there is no need for any actions to be done manually.

  1. Once the project is saved, MigrationWiz automatically opens both endpoints, connects to Microsoft Entra, and starts to configure the Microsoft 365 tenants for the project. This process can take up to one hour per 1000 users.
  2. Organizational Sharing and Individual Sharing are set up and enabled on the source and destination tenants; Free/Busy between the tenants.
  3. Users are discovered in the source tenant and mail contacts are created with an external email address of the primary domain on the destination tenant for the users. This will allow for reverse free/busy look-up from the destination to the source as well as enable mail routing from the destination to the source.
  4. Once the automatic process is finished, the users are imported into the MigrationWiz project. The users are now ready to have User Migration Bundle licenses applied.  See MigrationWiz Licenses for steps on applying for licenses. 

Litigation Holds

We do support Litigation Hold migrations but with some important known limitations.

​Be aware of these limitations since, for obvious reasons, Litigation Hold tends to have a 100% fidelity requirement. ​

All emails in the primary mailbox will indeed be migratedMigrationWiz also supports migrating of the Recoverable Items folder for the Archive mailbox for Exchange Online to Exchange Online only. Steps for this can be found outlined in the following migration guide: Recoverable Items (Microsoft 365 or Exchange) Migration Guide

Folders created in Litigation Hold are considered to be "email folders" but this is not necessarily the case. Therefore, all the special Litigation Hold items (whose type is not email) fail to migrate due to a known limitation in EWS (which is what MigrationWiz uses for migrations when migrating from Exchange 2007+ as the source).

Although they are not, several of these are considered email folders by EWS. Due to a bug in EWS, if you try to create a non-email item within those folders, it reports an error stating: "the item type does not match the folder type".

For example, if a contact is deleted, it will be stored in the /Purges folder. When we try to migrate this contact to the destination mailbox's /Purges folder, it reports an error.

Here are some known folders in the recoverable items mailbox:

  • Versions: If Litigation Hold (or for that matter, In-Place or single item recovery) is enabled, this subfolder contains the original and modified copies of the deleted items. Note: This folder is not visible to end users.
  • Purges: If either Litigation Hold (or single item recovery) is enabled, this subfolder contains all items that are hard-deleted. Note: This folder is not visible to end users.
  • Discovery Holds: If In-Place Hold is enabled, this subfolder contains all items that meet the hold query parameters and are hard-deleted.
  • Audits: If mailbox audit logging is enabled for a mailbox, this subfolder contains the audit log entries. This folder is not migrated with MigrationWiz.
  • Calendar Logging: This subfolder contains calendar changes that occur within a mailbox. This folder is not available to users.
  • Deletions: This subfolder contains all items deleted from the Deleted Items folder. (In Outlook, a user can soft-delete an item by pressing Shift+Delete.) This subfolder is exposed to users through the Recover Deleted Items feature in Outlook and Outlook on the web.

By default, the folders indicated above will be migrated into a folder at the Destination, named "Deletions". Any mail items within these folders will be migrated. The non-email items will return an error in the MigrationWiz portal, but will not prevent the migration from completing. Typically there are only a few extra errors caused when performing Litigation Hold migrations (since most items in these folders are, in fact, email items) so the error count threshold will not need to be adjusted.

The migration process includes a folder discovery, plus it attempts to retrieve items from within each folder. If the attempts fail, this folder will be excluded during the migration, so that the migration can continue.

If you prefer to have the folders in the recoverable items mailbox migrated into their own corresponding folders at the Destination, and not migrated into a folder named "Deletions", you must add the Advanced Option (under the support section): OverrideRecoverableItemsFolderMapping="^SourceFolder->DestinationFolder" to your project before performing your migration.

Here are the recommended step-by-step directions for performing a migration that includes mailboxes set for Litigation Hold:

  1. Create a regular mailbox migration project, set the advanced options, and submit mailboxes for migration. Follow the directions under the migration guide for the appropriate scenario. All migration guides can be found in the MigrationWiz category of the BitTitan Help Center.
  2. Once the mailbox migrations have been completed, create a new mailbox migration project specifically for Litigation Hold.
  3. Set the project advanced options for this Litigation Hold project, so that the Source: Migrate from: parameter is set to Recoverable Items. This will automatically set the Destination: Migrate to: parameter to be set to Recoverable Items.
  4. Return to the regular mailbox migration project dashboard, select completed migrated items, and move these items to the Litigation Hold project.
  5. Now, from the Litigation Hold project, submit items for migration. These will then migrate all items under the recoverable items folder at the source into the recoverable items folder at the destination.
  6. Once complete, move items back to the regular mailbox migration project.
  7. All emails will be migrated.
  8. Users will not be able to see anything that they should not be able to see.
  9. Mailbox migrations allow up to 10 passes per mailbox. Therefore, migrating mailboxes under the Litigation Hold project will not consume any additional licenses, provided that the items were moved between projects.
  10. Do not add new mailboxes under the Litigation Hold project. Instead, move items into this project. This way all project statistics and license history will be retained.​
  11. When migrating to recoverable options, it is recommended to increase the retention period for the deleted items folder. The default retention period is 14 days. This should be increased to the maximum, which is 30 days. Steps for this are included in this TechNet article:

Migrating Litigation Hold Data for Inactive Users

Inactive mailboxes are not supported with MigrationWiz. To migrate these users, activate them and migrate as part of a regular migration. Use the steps in this Microsoft document to restore the mailboxes to an active state before migrating: Restore an inactive mailbox

Litigation Hold vs. In-Place Hold

Litigation Hold migration involves putting a user's entire mailbox on hold to retain it for legal review.

In-place hold migration involves putting a subset of a user's entire mailbox on hold to retain only certain types of email.

The only difference between these two types of migration is a query. Litigation Hold can be enabled to hold all deleted or modified items. In-Place Hold is set up like Litigation Hold but adds a filter query to retain only specific kinds of email.

Litigation Hold works like this:

In the normal deleted item workflow, a mailbox item is moved to the Deletions subfolder in the Recoverable Items folder when a user permanently deletes it or deletes it from the Deleted Items folder. A deletion policy (which is a retention tag configured with a Delete retention action) also moves items to the Deletions subfolder when the retention period expires. When a user purges an item in the Recoverable Items folder, or when the deleted item retention period expires for an item, it is moved to the Purges subfolder in the Recoverable Items folder and marked for permanent deletion. It will be purged from Exchange the next time the mailbox is processed by the Managed Folder Assistant (MFA).

When a mailbox is placed on a Litigation Hold, items in the Purges subfolder are preserved for the hold duration specified by the Litigation Hold. The hold duration is calculated from the original date an item was received or created and defines how long items in the Purges subfolder are held. When the hold duration expires for an item in the Purges subfolder, the item is marked for permanent deletion and will be purged from Exchange the next time the MFA processes the mailbox.  If an indefinite hold is placed on a mailbox, items will never be purged from the Purges subfolder.

Increasing the Use of Administrator Credentials


Migrating Large Items

The steps in this article require that you connect to Microsoft 365 with Windows PowerShell. Refer to the Connect to Office 365 PowerShell article from Microsoft for detailed steps on how to connect to Microsoft 365 using Windows PowerShell.

To migrate items to Microsoft 365 that are larger than the EWS defaults, you will need to run the following PowerShell scripts.

First, you should run this script against your Microsoft 365 environment to determine what your current settings are:

Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize

The user can be any standard user on Microsoft 365 that has a Microsoft 365 license assigned that contains a mailbox license. It should be a user whose settings have not been previously modified.

Example results:

MailboxPlan: ExchangeOnlineEnterprise-4b910ff9-8b91-4f2e-960c-302a90c95668
MaxSendSize: 35 MB (36,700,160 bytes)
MaxReceiveSize: 36 MB (37,748,736 bytes)

Next, run this script against your Microsoft 365 environment to set the Mailbox Plan, the Max Send Size, and the Max Receive Size:

Get-MailboxPlan | Set-MailboxPlan -MaxSendSize 150MB -MaxReceiveSize 150MB

New users created after you change the mailbox plan will have 150MB as the max send and receive size. However, the current user will still have 35MB. To increase the limit for all users you can run:

Get-Mailbox | Set-Mailbox -MaxReceiveSize 150MB -MaxSendSize 150MB

The example below shows how you can validate that the new limits are applied:

PS C:\Windows\system32> Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize
MailboxPlan: ExchangeOnlineEnterprise-4e910ff9-8b91-4f2e-960c-302a90c65668
MaxSendSize: 150 MB (157,286,400 bytes)
MaxReceiveSize: 150 MB (157,286,400 bytes)

​Migrating Mailboxes Larger than 100GB

Follow these steps to migrate a mailbox larger than 100GB to Microsoft 365:

  1. Open MigrationWiz and create a mailbox migration project.
  2. Configure the Source and Destination Endpoints.
  3. Add the users to the project.
  4. Within the Advanced Options section, configure the destination settings to migrate to the Archive mailbox for the users. For additional information read the  MigrationWiz - Advanced Options & General Options article.
  5. Set a date range filter within the project to migrate items older than a specific date. For example, migrate all items a year old or older to the Archive mailbox. For additional information, read Set a date range filter in MigrationWiz.
  6. Submit a Full migration pass that migrates only mail items. Monitor the migration until it is successful.
  7. Once the migrations to the archive mailboxes are complete, change the setting in the Advanced Options to migrate to the primary mailbox instead of the archive mailbox.
  8. Remove the date range filter.
  9. Perform either a Pre-Stage or a Full migration pass to the primary mailbox.

Turn Off Calendar Assistant

Calendar Assistant in Microsoft 365 can break meetings and recurring meetings in Outlook and OWA. We recommend you turn off the Calendar Assistant at the beginning of any migration. This feature can be turned on after the migration has been completed. There is no negative impact when Calendar Assistant is turned off.

Use PowerShell to create a remote session to Microsoft 365 to execute the following commands:

$LiveCred = Get-Credential

Install-Module -Name ExchangeOnlineManagement
Import-Module -Name ExchangeOnlineManagement
Connect-ExchangeOnline -ConnectionUri -Credential $LiveCred

Get-o365Mailbox -ResultSize unlimited | Set-o365Mailbox -CalendarRepairDisabled $true

The Calendar Assistant is now disabled for all mailboxes in the Microsoft 365 tenant. It can be enabled again by using this PowerShell command:

Get-o365Mailbox -ResultSize unlimited | Set-o365Mailbox -CalendarRepairDisabled $false

Create an Admin Account

The easiest approach to follow is to use the global admin account. This was set up at the time of tenant creation.

However, if you do not wish to use this global admin account during migration, then a new user account can be created instead. This will then need to be granted full access rights to each mailbox user.


  1. Create a user in Microsoft 365: Create user mailbox in Exchange Online.
  2. Connect to Exchange Online by using remote PowerShell. For more information about how to do this, go to the following Microsoft website: Connect to Exchange Online Using Remote PowerShell
  3. Type the following command, and then press Enter:
    Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Admin')} | Add-MailboxPermission -User -AccessRights fullaccess -InheritanceType all

After you perform these steps, the specified user will be able to access all user mailboxes in Microsoft 365. The user will be able to view the contents of the mailboxes from either Outlook or Outlook Web App.

Migrating to Microsoft 365 in China

The first thing that needs to be done is to determine exactly which version of Microsoft 365 in China that you want to migrate to.

The key factor here is where Microsoft 365 resides, for example, whether or not Microsoft 365 is outside or inside the Chinese firewall.

The Chinese government runs and maintains the Great Firewall in China. There is an "international side" (outside the firewall) and a "mainland" side (inside the firewall). 

In MSPComplete, the "Microsoft 365 China" endpoint refers to "Micrsoft 365 China International." You can use this endpoint if you are migrating users to this international version of Microsoft 365 in China, the version that is outside the firewall.

However, if you are migrating to Microsoft 365 in China (inside the firewall), you should work with 21 Vianet. BitTitan has partnered with 21 Vianet to enable Partners to migrate to Microsoft 365 in China, inside the firewall. For more information on this partnership, read the blog here.

To initiate the process, contact 21 Vianet's sales department by sending an email to


Was this article helpful?
1 out of 3 found this helpful