Part 1.2 - Ways to migrate email to Exchange Online

Cutover Exchange Migration

This migration method relies on Outlook Anywhere (aka RPC/HTTP or OLA) and is suitable if:

• Your current on-premises Exchange organization is Microsoft Exchange Server 2003 or later.
• Your on-premises Exchange organization has fewer than 2,000 mailboxes, however, it is recommended that you only migrate up to 150 mailboxes due to the performance.

It will move ALL of the mail users, mail contacts, and mail-enabled groups with their membership besides the mailboxes and its contents (messages, calendar, contacts, tasks...)

Some of the disadvantages of this method are:

• Administrators or users must configure desktop computers, meaning you would need to create a new outlook profile once the mailbox has been migrated.
• Email sent to on-premises users whose mailboxes were migrated to EXO are routed to their on-premises Exchange mailboxes until the MX record is changed.
• When migrating from Exchange 2003, TCP port 6001, 6002 and 6004 need to be open on the Exchange 2003 side.
• If you have turned on directory synchronization, you need to turn it off before you can perform a cutover migration
• The migration administrator must be assigned the FullAccess permission for each on-premises mailbox, or the Receive As permission on the on-premises mailbox database that stores user mailboxes.
• You have to migrate all the mailboxes at once.

Apart from this, you need to make sure:

• The mailboxes you are going to migrate are not hidden from the GAL.
• Unified Messaging is disabled on the mailboxes you are going to migrate.

You can find more information about this migration method on the public article Opens in new window or tab .

Staged Exchange Migration

With this migration method you can migrate the contents of user mailboxes from an Exchange 2003 or Exchange 2007 organization to EXO over time, and will rely on Outlook Anywhere just like a cutover migration would do.

This migration method is suitable if:

• Your source email system is Microsoft Exchange Server 2003 or Microsoft Exchange Server 2007 (You can't use a staged migration to migrate mailboxes hosted on Exchange 2010 or higher to EXO and you should consider using a cutover migration or a hybrid email migration instead)
• You have more than 2,000 mailboxes and you want to migrate them over time.

Some key points to keep in mind:

• You need AADConnect in place so it syncs the accounts between your local AD and AAD (pretty much to have a synced environment, not a hybrid).
• The vanity domain in use by your mailboxes (i.e.: contoso.com Opens in new window or tab ) should also be added and verified in your Office 365 tenant, and therefore show up as an accepted domain on EXO.
• you need to define the mailboxes you will be migrating on a CSV file to create the migration batches you'll be running.

Listing some limitations of this migration method:

• Out of Office messages aren't migrated with user mailboxes.
• The same way it happens with a cutover migration, Administrators or users must configure desktop computers, meaning you would need to create a new outlook profile once the mailbox has been migrated.
• Administrators need to have access to the user mailboxes data.
• Once the migration is complete for a mailbox, the administrator needs to manually convert the mailbox into a MailUser object Opens in new window or tab .

Here are the detailed steps on how to perform a staged migration Opens in new window or tab .

IMAP Migration from Exchange

Because Exchange also offers the possibility to connect to the mailboxes using the IMAP protocol, it's also a possible way of migrating content and therefore is not limited to third-party E-mail systems. Of course, you won't have all the benefits other migration methods may offer you.

Besides of what was described on the Third Party E-mail systems section of this page, when migrating content from an Exchange On-premises environment using IMAP you have to be aware of the additional limitations:

• Microsoft's data migration tool is currently unaware of tools enforcing messaging records management (MRM) or archival policies. Because of this, any messages that are deleted or moved to archive by these policies will result in the migration process flagging these items as "missing". The result is perceived data loss rather than actual data loss, which makes it much harder to identify actual data loss during any content verification checks.Therefore, Microsoft strongly recommends disabling all MRM and archival policies before attempting any data migration to mailboxes.
• You can only migrate items in a user's inbox or other mail folders. This type of migration doesn't migrate contacts, calendar items, or tasks.
• You can migrate a maximum of 500,000 items from a user's mailbox (emails are migrated from newest to oldest).
• The biggest email you can migrate is 35 MB.
• If you limited the connections to your source email system, it's a good idea to increase them to improve migration performance. Common connection limits include client/server total connections, per-user connections, and IP address connections on either the server or the firewall.

EWS Migration (via 3rd party migration solutions)

Exchange Web Services (EWS) is a legacy protocol that has been in usage since Exchange Server 2007 and that there hasn't been (and will not be) any further improvement on it since August 2018. Instead we recommend customers and 3rd party solutions to rely on Microsoft Graph instead, but we still allow EWS connections, so it's also a possible migration method.

There's really not much to say on this migration method rather than it relies on the EWS protocol and that the logic being applied depends fully on the design of the 3rd party tool, however, depending on how that tool has been designed and on how many calls it does to the source and target Exchange organizations, EWS throttling will be applied if needed to.

Wait, "thro...what?", Throttling in Exchange helps to ensure server reliability and uptime by limiting the amount of server resources that a single user or application can consume. In other words, throttling is a reactive response to overuse of system resources that may affect service reliability and functionality. This reactive response is typically an interruption of the session, an error being returned, or a long pause for the ongoing operation.

EWS throttling is a very long and interesting topic to understand, and even though is not mandatory for you to know at this stage, it's highly recommended for you to read the public article we have called "EWS throttling in Exchange" Opens in new window or tab .

Besides EWS throttling, some 3rd party migration tools rely heavily on Powershell as well for management tasks, and guess what, we do have throttling applied to PowerShell in Exchange as well (on-premises and online).

If your customer is relying on a 3rd party tool to migrate the content as is experiencing a throttling related issue, it's very important to ask what type of throttling is being experienced (EWS, PowerShell, both?), and then direct them to the self-service diagnostics available from the Office 365 admin portal Opens in new window or tab for each scenario.

• For the EWS throttling one, you may ask the customer to type 'Migration Exchange Web Services (EWS) throttling policy' on the 'How can we help' search box and make sure to check the checkbox informing this is for a migration to the proper values will get applied for a period of time.
• For the PowerShell throttling one, you may ask the customer to type 'Exchange Remote PowerShell throttling policy' on the 'How can we help' search box.

If after the new throttling settings were applied, they still have throttling related issues, then the 3rd party tool being used needs to be tweaked so it doesn't consume that much resources. Nothing we can do on that matter.

Hybrid Migration (aka as remote moves)

This is going to be the migration method we will be deep diving since it's the preferred way of having large organizations that rely on Exchange On-premises migrate to EXO in a controlled and scheduled way over time while having most of the Exchange features while it gets done.

This (as we will see along this module) relies on the Microsoft Exchange Replication Service (MRS) among others and it's by far the most reliable migration method of all the ones previously mentioned; and by the contrary of the other migration methods, even though is often used by large companies, there's no minimum or maximum limit on the number of mailboxes you can migrate (not to mention you don't have to recreate the Outlook profiles).

But let's stick to the module itself and not just learn about the pro's and con's of this, but also get a basic understanding and learn how to troubleshoot remote moves.

Native Cross-Tenant Mailbox Migrations (aka as T2T mailbox moves)

Until now, if you wanted to move mailboxes from one EXO tenant to another, you would have to rely on 3rd party migration tools to do this job (and you still can), but the question everyone was asking was 'if the mailboxes are stored on our datacenters, why can't Microsoft just move them?'

Well, it's a very fair question, so PG decided to take advantage of the remote moves, without having the need to establish a hybrid environment between both tenants, we still need to trust in some way the target tenant to access the source tenant mailbox information, but it's a bit different than what a hybrid environment would be like.

Think about the following scenarios this migration method would be applicable for:

• Mergers or acquisitions ('Company A' buying 'Company B')
• Divestitures (part of 'Company A' becoming 'Company B')
• Rebranding ('Company A' becoming 'Company B')

We will be digging further into this migration method later on this module.

?? IMPORTANT: If you're using a 3rd party solution to migrate, depending on what the tool relies on, it may be necessary to increase the EWS and/or PowerShell throttling limits for the tenant. This is not applicable to hybrid moves.

?? NOTE: None of the migration methods will delete the content from the source mailbox, but will be syncing the contents, meaning that if the user deletes messages from the source mailbox, those will also be deleted on the EXO mailbox.

?? NOTE: All of the migration methods (except for those driven by 3rd party tools) are initiated from EXO, meaning EXO will always be the one connecting to the source system and pull the data.