Blog Post

Exchange Team Blog
10 MIN READ

Choosing and Troubleshooting Exchange Online Mailbox Migrations

The_Exchange_Team's avatar
Nov 09, 2023

There is a lot of great documentation on Exchange Online migrations. The issue can be knowing where to start. This blog post is a consolidation of information and aims to help you understand various types of Exchange Online migration options, how you would pick the right one, how to prevent issues and what to do if something goes wrong.

In this post, we will focus on Exchange Online migrations using Microsoft tools only. We will not cover 3rd party, public folder, or PST import requests.

Types of migrations

Exchange Online migrations can be categorized in several ways.

Considering directionality, we have 2 types:

  • Onboarding (migration to Exchange Online)
  • Offboarding (migration from Exchange Online)

Both types of migrations are initiated from Exchange Online, typically using Exchange Online admin center (EAC).

If we consider connection protocol used, we have 4 main types:

  • Mailbox Replication Service (MRS) migrations: Exchange remote move migrations that use MRS. Commonly known as Exchange hybrid migrations. Our cross-tenant migration uses the same technology. These are known as Move Requests or ExchangeRemoteMove type. They use PowerShell commands like New-MoveRequest, Get-MoveRequest, Get-MoveRequestStatistics.
  • IMAP migrations: use the IMAPv4 protocol. These are known as sync requests. They use Exchange Online PowerShell commands like New-SyncRequest, Get-SyncRequest, GetSyncRequestStatistics.
  • Google Workspace (formerly known as G Suite) migrations. These were initially IMAP migrations but for several years now they use REST protocol. These too are sync requests.
  • Outlook Anywhere migrations: legacy migration method that uses RPC/HTTP protocol. These can be split into Staged and Cutover migrations. They are known as merge requests. PowerShell commands are not exposed to tenant admins but in the background, the service uses New-MergeRequest. You can only use Get-MigrationUser and Get-MigrationUserStatistics cmdlets here.

When it comes to MRS request type, all native Exchange Online migrations use MRS behind the scenes to migrate mailboxes. Types of MRS requests differ as we have seen above: Move requests, Sync requests and Merge requests.

Based on all these parameters, I have created the following table:

Migration

Direction

Protocol

MRS Style

Source

Target

Supported server

Hybrid Move to Exchange Online

Onboarding

MRS – MRSProxy

Move request

Exchange on-premises

Exchange Online

Exchange Server 2010 or later

Hybrid Move  from Exchange Online

Offboarding

MRS – MRSProxy

Move request

Exchange Online

Exchange on-premises

Exchange Server 2016 or later
(Offboarding to earlier versions is blocked)

Cross Tenant

Offboarding Tenant A
Onboarding Tenant B

MRS – MRSProxy

Move request

Exchange Online

Exchange Online

n/a
(migration within Exchange Online)

Google Workspace

Onboarding only

MRS – REST

Sync request

Google Workspace

Exchange Online

Google Workspace

IMAP

Onboarding Only

MRS – IMAP

Sync request

IMAP server

Exchange Online

Any IMAPv4 capable server

Cutover

Onboarding Only

MRS – RPC/HTTP

Merge request

Exchange on-premises

Exchange Online

Exchange Server 2003+
*For Exchange 2010 or later, recommended to use hybrid moves. We plan to deprecate these and give non-hybrid organizations the ability to inject Remote Moves. If the admin doesn’t have the ability to enable MRSProxy, they’ll use IMAP or PST import.

Staged

Onboarding only

MRS – RPC/HTTP

Merge request

Exchange on-premises

Exchange Online

Exchange Server 2003 and 2007

If you need more help with choosing the migration path, please consult our Migration Advisor Tool. Documentation for the tool can be found here.

Here is a quick look at the Migration Advisor:

Hybrid migrations

Exchange hybrid organization is an organization that has on-premises Exchange Server and Exchange Online mailboxes that coexist and act as a single Exchange organization. Mailboxes are migrated between Exchange on-premises and Exchange Online. There are several flavors of Exchange hybrid, such as Modern versus Classic, Multi-Tenant Exchange Hybrid, Multi-forest Exchange Hybrid but from hybrid migrations perspective, we will focus on Full Hybrid, Minimal and Express options.

Full hybrid is for organizations that want to coexist long term and need to maintain directory synchronization in the environment. Minimal / Express is for short term coexistence, involve fewer mailboxes and usually mailboxes are all migrated at once. The difference between Minimal and Express is the directory synchronization process. Express option does a one-time synchronization of users and passwords automatically (to provision the users in Exchange Online) and then disables directory synchronization. You don’t need to enable directory synchronization before this type of migration. You would typically not use this option if you already enabled directory synchronization.

Additional resources on hybrid migrations and troubleshooting:

Mailbox migrations in Exchange Online use migration batches. The only migration type that does not have to use migration batches and you can inject move request directly, is hybrid migrations. See the section “Onboard or offboard with PowerShell” from this blog post to inject move requests directly (most should not need this).

Primary mailbox / archive mailbox migrations

In hybrid migrations, you can onboard both the primary and archive mailbox or only the archive (this is called a cross-premises archive scenario, where the primary mailbox is hosted on-premises, and the archive is in Exchange Online). Note that you cannot have an Exchange Online primary mailbox with an on-premises archive (only the opposite is supported).

For onboarding and offboarding only the primary mailboxes when archive exists, please see this article as the GUI does not currently support this.

On-premises, a user can have only one primary mailbox and a single main archive. In Exchange Online users can have multiple Auxiliary archives (AuxArchive) besides user’s MainArchive, thanks to the Auto-Expanding Archive feature.  Once the user has Auxiliary archives created in Exchange Online, you cannot offboard the archive mailbox to Exchange on-premises because Exchange on-premises does not support Auxiliary archive capability.

Tenant to tenant (T2T) or cross-tenant mailbox migrations

With cross-tenant mailbox migrations, it is possible to migrate Auto-Expanded archives. Up to 12 are currently permitted for migration by default.

For troubleshooting cross-tenant migrations, this article and the command Test-MigrationServerAvailability -TestMailbox <> -Endpoint <>  are your best friends.

Another useful tool is this script written by Alberto Pascual Montoya and published on CSS-Exchange GitHub repo. This script will check and validate various related user and organization settings.

IMAP Migrations

See the official documentation on Migrating IMAP mailboxes and check the sub-articles from the left side navigation:

Other useful articles for IMAP migrations:

Google Workspace migrations

See the documentation on Perform a Google Workspace Migration and related articles:

Cutover migrations

For Cutover migrations see the following:

Staged migrations

For Staged migrations see the following:

What types of content gets migrated?

The following table provides an overview of data we can migrate.

Migration

Content Migrated

MRS Moves

All Exchange data stored in the mailbox, including Recoverable Items (example Deletions, Versions, Purges, DiscoveryHolds).
* For offboarding to on-premises or cross-tenant, we don’t migrate non-Exchange data like SubstrateHolds or TeamsMessagesData folders. This will remain in the Source ComponentShared mailbox.

Google Workspace

Email, Calendar, Contacts

IMAP

Email

Cutover

Email, Calendar, Contacts, Tasks

Staged

Email, Calendar, Contacts, Tasks

More detailed information can be found here.  

You can exclude folders or use content filters when doing IMAP and Google Workspace migrations.

Mailbox and message size limits

Exchange Online mailboxes have various limits. Most common limits encountered during migrations are:

  • Recoverable Items folder cannot have more than 3 million items. As an example, you cannot migrate a mailbox that has more than 3 million items in Recoverable Items\Purges folder. Other mailbox folders (like Inbox or Sent Items) cannot have more than 1 million items.
  • For IMAP migration, we cannot migrate more than 500,000 items.
  • Default Exchange Online message size is 35MB for new mailboxes. This can be increased up to 150 MB with commands like Set-Mailbox -MaxReceiveSize 150MB. This can apply to an IMAP migration where we need to provision a mailbox in Exchange Online before starting the migration and you have email items bigger than 35 MB on the IMAP source side, or you might need to run Set-MailUser -MaxReceiveSize 150MB for a Mail User during hybrid onboarding.
  • Mailbox and Archive quotas by default have a maximum of 100 / 110 GB per mailbox.
  • With Google and IMAP migration it is now possible to migrate larger mailboxes. See Migrate large mailboxes from Google or other IMAP sources.

User provisioning requirements for Exchange Online migrations

  • For MRS onboarding, Cross-tenant, Google Workspace, or Staged migrations you need to ensure that corresponding Mail Users are created in Exchange Online. For Staged and MRS onboarding, this is done automatically by directory synchronization; for each corresponding Exchange on-premises mailbox synced with AADConnect tool we will have a mail user object in Exchange Online. For Google Workspace and Cross-tenant migrations, usually this is done via PowerShell scripts, here is an example of a script.
  • For Cutover migration, there is no need to provision an object on the target. If already created, it must be a Mailbox type with attributes matching the Exchange on-premises mailbox object (UPN, alias, email addresses).
  • For IMAP migration, we need to provision a mailbox in Exchange Online before migration.

MIGRATION TYPE

Source

Target

Recipient in source

Recipient in target

Exchange Hybrid (MRS move) - onboarding

Exchange on-premises hybrid Org A

Exchange Online hybrid Org A

Mailbox

Mail User with matching attributes (Directory Synchronization)
 

* Express Migration synchronizes the users automatically so there is no need to provision mail users or enable directory synchronization

Exchange Hybrid (MRS move) - offboarding

Exchange Online hybrid Org A

Exchange on-premises hybrid Org A

Mailbox

Mail User / Remote Mailbox with matching attributes

Cross-tenant (MRS move)

Exchange Online Tenant A

Exchange Online Tenant B

Mailbox

Mail User with matching attributes

Cutover

Exchange on-premises

Exchange Online

Mailbox

None (migration service creates the mailbox in Exchange Online based on the on-premises GAL)

Staged

Exchange on-premises

Exchange Online

Mailbox

Mail user with matching attributes (Directory Synchronization)

Google Workspace

Google Workspace

Exchange Online

Mailbox

Mail User (migration service converts to mailbox in Exchange Online)

IMAP

IMAP server

Exchange Online

Mailbox

Mailbox

Several additional provisioning-related notes:

  • For Hybrid and cross-tenant moves the target Mail User is converted to a Mailbox at the end of the move (in a phase called UpdateMovedMailbox). In that phase, source Mailbox is converted to a Mail User. For recipient conversions failures in hybrid migrations, please see the blog post What to do if a migration is Completed With Warnings (Part 5).
  • When onboarding to Exchange Online is successful, the on-premises Exchange source mailbox goes into a disconnected state. It will be kept according to the mailbox retention set on the on-premises mailbox database.
  • In cross-tenant moves and offboarding migration, when the source mailbox is in Exchange Online, we convert the primary mailbox to a ComponentShared mailbox (a mailbox that has only non-Exchange data).
  • For Google Workspace migration, Mail Users are converted to Exchange Online mailboxes once the migration batch is started. For Google Workspace, IMAP, Cutover and Staged migrations, because we are working with 2 active mailboxes at the same time (source and target), this is a merge request type rather than a move request type migration.
  • Be mindful of the incremental synchronization process that will sync any changes from the source mailbox to the target mailbox. If users delete something from the source mailbox, this will be synced to the target mailbox. Google Workspace and IMAP migrations soft delete the data in the target Exchange Online mailbox when data is deleted from the source mailbox during migration.

Completing migrations

There are 3 migration types that have the “Complete migration” functionality: Hybrid moves, Cross-tenant moves and Google Workspace migrations.

For completing a migration batch, we have 3 options:

  • Manually complete the batch (this is the default option)
  • Automatically complete the batch
  • Automatically complete after a date and time

These options are useful because many companies choose to finish migration (switchover) during the weekend or non-working hours. Mailboxes will be temporarily unavailable during the switchover.

Sometimes, you will see that the migration is not completed even if you set the automatic complete option.  This might be because the batch has a low Data Consistency Score (DCS). DCS score of “Investigate” means that there are corrupt / large / missing items encountered during the migration and we warn the admin about potential data loss. Admin action is needed. If you get a score of “Poor”, it means there is possibility of major data loss, and you’ll need to contact our support and will not be able to approve the skipped items nor complete the migration.  The scores that do not need approval from admin and can be completed are “Good” and “Perfect”. More on DCS can be found here and here.

For Google Workspace migrations where we have live mailboxes in the target, is it possible that you will need to approve skipped items multiple times, because new corrupt / large / missing items might continuously appear after you already approved skipped items. The MissingItemInTarget error can be seen when the end-user or a process like MRM delete or move data from folders that migration already copied data to, in the target mailbox. Since migration already copied the item but then it is found missing, the error can be displayed.

Additional reading

Migration permissions and CSV files for migration:

Understanding migration limits, best practices and duration estimates for migrations:

From the last article, I would like to call out Duration Estimates for Onboarding Migrations from Exchange Server and cross tenant migrations. Those are very common questions we get from customers. You would open a support case with us if “P90” (see article tables) is exceeded and it is due to delay on Exchange Online side.

When it comes to third party migrations using EWS protocol, please be aware that we have a self-serve diagnostic to temporarily relax EWS throttling for migration purposes. See Self-help diagnostics for issues in Exchange Online and Outlook. Note that this has no effect on Microsoft migration tools for Hybrid, IMAP, Google Workspace, or public folders.

This completes our guide on Exchange Online mailbox migrations. I would like to thank Nino Bilic, Angus Leeming and Timothy Heeney for contributing and reviewing this post.

Mirela Buruiana

Updated Mar 20, 2024
Version 2.0
No CommentsBe the first to comment