Office 365 Mailbox Migration FAQ

Migration Planning

By default, Office 365 has a 25MB per item limit. From a practical perspective, the limits are a bit lower due to protocol overhead and encoding. As a result, items larger than 20MB in size may fail to migrate. However, you can increase this limit by following the instructions in this blog post from Microsoft.

Office 365 imposes a limit of 10 connections per admin account. If you're submitting more than 10 mailboxes concurrently, you may run into throttling-related errors such as "Connection did not succeed" and poor performance. You may use impersonation as a way to resolve this problem.



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 in to the mailbox.

To further explain this, here are examples:

  • If the account has been created at the Destination but no one has ever logged into the account, then whatever language is set within MigrationWiz Advanced Options via this Destination mailbox language setting will be the language that OWA interface is set to. It will not perform any translation on actual mailbox content.
  • If the account has been logged in to prior to migration, this MigrationWiz Advanced Option setting will not have any effect. This setting only effects mailboxes that have never been logged in to, before migration. For example, if the user logs in to OWA and sets their OWA language to German, but the MigrationWiz Advanced Option language setting is set to French, the OWA interface language will remain set as German.
  • This setting does not handle any mapping of system or user folders from one language to another, or to/from the same language. Folder mapping must be added if/as desired.


Set msExchMailbox GUID attribute to null

This can be set within 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 AAD Sync, or AAD Connect.
  • For more details on the correct order of steps to follow for directory synchronization, refer to KB004336.


Run the Synchronization Rules Editor as an administrator.



Click In from AD – User Exchange to edit the Inbound Rule Type.



Select Transformations.

Find the msExchMailboxGuid attribute.

Change it to the following:

Expression - msExchMailboxGuid - NULL - Checkmark Apply Once 

Click Update



Next, enable AADSync or AAD 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 Office 365.



Access & Credentials

There are multiple ways to manage credentials in Office 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 Auth

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

The Autodiscovery of items option will not work with Modern Authentication in place.


  • A Global Administrator account with access to Azure Active Directory.
  • MigrationWiz® Mailbox project(s) created and ready for configuration.
  • The application will require administrator consent. This process will include the steps for granting that consent. For more information on granting administrator consent, see this article from Microsoft: Configure the way end-users consent to an application in Azure Active Directory


  1. Log in to Azure AD admin console at: with a Global Administrator login.
  2. Select Azure Active Directory in the Azure Active Directory Admin Center.
  3. Select App Registrations, which is found under Manage.
  4. Select New Registration at the top of the screen.
  5. Give the app a distinct name. You can change this later if necessary.
  6. Select the Accounts in any organizational directory button.
  7. Under Redirect Uri, select Public Client (mobile & desktop) and set it to urn:ietf:wg:oauth:2.0:oob
  8. Click Register.
  9. Go back to App registrations.
  10. Select the App you just created.
  11. In the Overview, you will find a ClientId (aka Application) and Directory (Tenant) ID.
  12. Copy both of these to another application, such as Notepad, for use later in this process.
  13. Under the Manage menu, select Authentication.
  14. Set the option Treat application as a public client to Yes. This does not open public access; it indicates that the client is not capable of protecting the Open Authorization client secrets. A different authentication mechanism will be needed.
  15. Click Save.
  16. From the Manage menu, select API permissions.
  17. Select Add a Permission.
  18. Select Exchange from Supported Legacy APIs.
  19. When asked “What type of permissions does your application require?” click Delegated permissions.
  20. Check the box under EWS for EWS.AccessAsUser.All.
  21. Click Add permissions. This permission only allows the OAuth application (MigrationWiz) to be associated with EWS. This does not grant access to all mailbox data.
  22. Click Grant admin consent.
  23. Click Yes to confirm the settings.
  24. In MigrationWiz select the project that needs to be configured for Modern Authentication.
  25. Click the Edit Project menu.
  26. Select Advanced Options.
  27. Under Support Options enter the ClientID and TenantID information you saved earlier in the following format:
    • If enabling Modern Authentication for the Source:
      • ModernAuthClientIdExport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      • ModernAuthTenantIdExport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    • If enabling Modern Authentication for the Destination:
      • ModernAuthClientIdImport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      • ModernAuthTenantIdImport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 
        • Enter the specific ClientID and TenantID for your tenant in place of the xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
        • These options can be entered for either the Source or the Destination, or both, depending on the settings on the tenants. These options need to be configured for each MigrationWiz project that needs to have Modern Authentication enabled.

  28. Run a Verify Credentials to confirm that MigrationWiz can connect using Modern Authentication. 
  29. Click on the item that was verified. There will be a message in the MigrationWiz Migration Information page that Modern Authentication is being used. This message will show in the “Migration Errors” box; however, it is not an error. This is just a message confirming that Modern Authentication is now active and being used for connection.


Verifying Mailbox Access

Perform the following steps to verify mailbox access.

  • Browse to
  • Log in as admin email address.
  • Enter the exact same password as specified in MigrationWiz.
  • Enter the Admin portal.
  • Click on Users, then Active Users.
  • 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.
  • Make sure all users have licenses assigned to them (see here if using F1 Office 365 licenses). All mailboxes on the Source system are created as mail users in Office 365. When you assign a license to the mail user, it will become a mailbox user. We need a mailbox at the Destination in order to be able to migrate data.
  • 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.
  • If you deleted and recreated users, make sure the users have been hard-deleted from the Deleted users tab in the Office 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 Office 365.
  • When you submit the project for migration, we try to automatically grant the administrator account permission on mailboxes (using impersonation), by executing Office 365 PowerShell commands. In some cases, the Office 365 PowerShell command may fail. If done manually, the issue should be resolved. (The article, How do I migrate to Exchange or Office 365 using impersonation? explains how to do 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:
    • Wait 30 minutes and resubmit the migration.

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


Migrating permissions for user-created folders

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 to MustMigrateAllPermissions=1 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.


Impersonation in Office 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:

  • Use admin credentials at the Destination.
  • Sign in to the MigrationWiz account.​
  • Edit the Project and click on Advanced Options.
  • If migrating from Office 365, under Source, check Use impersonation to authenticate.
  • If migrating to Office 365, under Destination, check Use impersonation to authenticate.
  • Click on 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>

To learn how to run these commands manually, click here. 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 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 on 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 on 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 Office 365 section, to enable support for 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 Azure Active Directory 

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 AAD Sync or AAD Connect (if you need support for federation).
  2. Set msExchMailbxoGuid to Null.  Read How can I set msExchMailboxGuid attribute to null for more information.
  3. Configure filtering to define which objects are synced. Read the Azure AD 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 Office 365.
  5. Assign Office 365 licenses to accounts on Office 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 this is not supported by DirSync. 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 Office 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 Office 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, Office 365 accounts can be created using one of the following methodologies. 

    • AAD Sync or AAD Connect. Follow the instructions detailed in the recommended approach above.

    • Manually, one at a time.

    • By bulk import, via CSV file.

    • BitTitan DirSync tool.

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 Office 365 using MigrationWiz, mailboxes need to be provisioned on Office 365 in order to be able to write the content, mail, contacts, calendar, etc. (the user must exist on Office 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 Office 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 Office 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 Office 365 prior to migration since, as explained above, the mailbox needs to be active in order for MigrationWiz to migrate data into it.

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

If John sends an email to Tom, Office 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 Office 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 Office 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 Office 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 Office 365 admin portal. If you need information about how to do this through the Office 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 Office 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

Office 365 Tenant to Tenant Coexistence provides coexistence functionality for O365 to O365 migrations. When performing an O365 migration and cutover is planned for a later date, migrations are done in batches. These types of migrations 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.

Important: Office 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.

Important: Azure Active Directory Connect (ADFS, AADConnect, AADSync, ADSync, etc.) cannot be used to do anything with the destination user accounts until after the migration project is fully completed.


Setting up the Office 365 Tenant to Tenant Coexistence

  1. Launch MigrationWiz and create a Mailbox project.  For help creating a Mailbox Migration project, see How do I create a new mailbox migration project?
  2. Set up the Source and Destination endpoints as Office 365. 
  3. Enable Tenant to Tenant Coexistence by selecting the checkbox during the initial project creation.Enable.png
  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. 
      Important: 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 Office 365 License: Select the Office 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 Office 365 licenses are supported for this migration. The supported types are listed in the Migration Setup drop-down menu. Only one Office 365 license type can be used per project and the Office 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.

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

One 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 absolutely 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 mailboces. 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 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 Office 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 Azure Active Directory, and starts to configure the Office 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 Apply User Migration Bundle licenses to the Customer's Users for steps on applying licenses. 

Litigation Holds

By default, mailboxes for inactive users with litigation hold are not migrated by MigrationWiz®. Because the users are not licensed in the destination system, the mailboxes are not created, and the held items do not have a location to be migrated to.

It is possible to set up a migration specifically to migrate these held mailboxes. Use the steps below to create a project and migrate litigation hold data for inactive users in an Office 365 to
Office 365 tenant migration scenario:

  1. Find all inactive mailboxes. This can be done using the Powershell command below.
    Get-Mailbox -InactiveMailboxOnly -ResultSize Unlimited
  2. Add inactive users to MSPComplete either individually (Quick Add) or using a CSV (Bulk Add). For specific steps see View, Add, and Edit Customer’s Users.
  3. Create the target mailboxes in the destination Office 365 tenant.
  4. Add licenses to the newly created mailboxes in Office 365. (This requires at least an E3 license.)
  5. Set litigation hold on the new mailboxes.
  6. Set all the new mailboxes as Inactive. This will also remove the Office 365 license from those mailboxes.
  7. Create a new MigrationWiz Mailbox project. For more information, see How do I create a new migration project?
  8. Do not check the box for Tenant to Tenant Coexistence.
  9. Click Save Project.
  10. Add the email addresses for the inactive users to the project. The source email addresses must match the inactive mailbox UPNs. The destination email addresses should be the newly created email addresses that were created earlier in these steps. For help with this, see How do I add items to my migration project?
  11. Once the project is created, click Edit Project and select Advanced Options.
  12. Under both the Source and Destination sections, click Recoverable Items.
  13. Click Save.

The migration is now ready to be run. Other changes can be made if your scenario requires them, but no other settings are required to migrate mailboxes for inactive users.

If this migration fails, recover the inactive mailboxes before retrying the migration of the Recoverable Items.  Use the steps in this Microsoft document to recover the mailboxes: Recover an inactive mailbox in Office 365, then run the migration again when the mailboxes are recovered.



Migrating Large Items

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

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

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

Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize

The user can be any standard user on Office 365 that has an Office 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 Office 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 Office 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  What are my mailbox or archive migration 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 the How do I set a date range filter in MigrationWiz? article.
  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 now migrate to the primary mailbox instead of the archive mailbox.
  8. Remove the date range filter.
  9. Perform either a Pre-Stage migration or a Full migration pass to the primary mailbox.


Turn off Calendar Assistant

Calendar Assistant in Office 365 can break meetings and recurring meetings in Outlook and OWA. We recommend that Calendar Assistant is turned off at the start of any migration. This feature can be turned again on after the migration has completed. There is no negative impact when Calendar Assistant is turned off.

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

$cred= Get-Credential

$o365= New-PsSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $cred -AllowRedirection -Authentication Basic

Import-PsSession $o365 –Prefix o365

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

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

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


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