This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
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 |
Onboarding |
MRS – MRSProxy |
Move request |
Exchange on-premises |
Exchange Online |
Exchange Server 2010 or later |
|
Offboarding |
MRS – MRSProxy |
Move request |
Exchange Online |
Exchange on-premises |
Exchange Server 2016 or later |
|
Offboarding Tenant A |
MRS – MRSProxy |
Move request |
Exchange Online |
Exchange Online |
n/a |
|
Onboarding only |
MRS – REST |
Sync request |
Google Workspace |
Exchange Online |
Google Workspace |
|
Onboarding Only |
MRS – IMAP |
Sync request |
IMAP server |
Exchange Online |
Any IMAPv4 capable server |
|
Onboarding Only |
MRS – RPC/HTTP |
Merge request |
Exchange on-premises |
Exchange Online |
Exchange Server 2003+ |
|
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:
- Exchange Hybrid Migrations: More Than Just a Pretty Face
- Digging Into Hybrid Migration Move Report Data (Part 2)
- Troubleshooting Failed Migrations (Part 3)
- Troubleshooting Slow Migrations (Part 4)
- What to do if a migration is Completed With Warnings (Part 5)
- Understanding Hybrid Migration Endpoints in Classic and Modern Hybrid
- Troubleshooting Hybrid Migration Endpoints in Classic and Modern Hybrid
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:
- Use PowerShell to perform an IMAP migration to Microsoft 365
- Troubleshoot IMAP migrations
- IMAP Migration Troubleshooter
Google Workspace migrations
See the documentation on Perform a Google Workspace Migration and related articles:
Cutover migrations
For Cutover migrations see the following:
- What to know about a cutover migration
- Cutover migration to Office 365
- Use PowerShell to perform a cutover migration
Staged migrations
For Staged migrations see the following:
- What to know about a staged migration
- Perform a staged migration
- Convert Exchange 2007 mailboxes to MEU
- Convert Exchange 2003 mailboxes to MEU
- Use PowerShell to perform a staged migration to Microsoft 365
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). |
Google Workspace |
Email, Calendar, Contacts |
IMAP |
|
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.
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:
- Permissions for Migrations - permissions admins need to perform mailbox migrations
- CSV files for Migrations - a CSV file specific to each migration type containing information about users to be migrated
Understanding migration limits, best practices and duration estimates for migrations:
- The 100 migration batches limit and how to not run into it
- Understanding Migration Concurrency
- Resource Based Throttling and Prioritization in Exchange Online Migrations
- Office 365 Migration Best Practices
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