mail migration to office 365 | Migration methods

The subject of: mail migration to Office 365 includes many aspects such as:

• Choose the suitable migration plan\method, based on the organization mail infrastructure organization requirement and so on.
• Create a mail migration plan
• Create a mail migration pilot
• Estimate the mail migration throughput – Provide to the organization management an estimate of the resources that are required for the mail migration project and estimation of the time that it will take to complete the organization mail infrastructure to Office 365 (Exchange Online).

The point of this article

In the current article, we will review optional mail migration tools\methods that we can use for implementing mail migration to Office 365, and the focus is on the way that each of this mail migration methods uses for migrating the data to Exchange Online.

The information about the different methods doesn’t include a “How to” instruction and doesn’t include a comprehensive review on each of the features for the mail migration option but instead, focus on the subject of “how is the data migrated” when using different mail migration methods.

Office 365 – Mail migration technology

A quick reference for the article series

	Mail migration to Office 365| Factors that impact mail Migration throughput | Part 2/4 The second article includes a review the different factors that impact the performance of the mail migration throughput.
	Mail migration to Office 365| Optimizing the Mail Migration throughput | Part 3/4 The third article recommendation and best practices for improving and optimize the performance of the mail migration throughput.
	Mail migration to Office 365 | Measure and estimate Mail Migration throughputs | Part 4/4 The last article in this series is dedicated to information about the “expected mail migration throughput” and includes a nice Excel based utility (Office 365 – Multiple and Single Mailbox Migration throughput calculator) that will help us to provide an estimation for the expected data transfer rate. Based on this information we can provide a reasonable “end date” for the completion of the mail migration project.

Mail migration to Office 365 | Methods and classifications

There are many available options that we can choose from for accomplishing the task of: mail migration to Office 365.

1. Microsoft Office 365 built-in mail migration tools
2. Third party mail migration tools
3. PST migration

Mail migration to Office 365 – Methods and classifications

Mail migration method Server to server versus Client to server

Method 1: Mail migration “server to Server”

An example for the Mail migration that I describe as: “server to Server” is the Office 365 built-in mail migration tools that are based on a “server to server” mail migration concepts in which the Exchange Online is the component that connects to the “other side” (the organization’s mail server) and “pull out” the data from it.

The additional basic concept is that the “destination server” the mail server that hosts the mailboxes is Exchange server.

Office 365 built-in mail migration tools – Server to Server method

The exception to the rule that the “destination server” is an Exchange server is the option of IMAP mail migration. The IMAP migration was designed for scenarios in which the organization’s mail server is not an Exchange server, but instead other mail product that can enable to “pull” the data (user’s mailboxes) by using the IMAP protocol. For example, when we want to migrate, a mail infrastructure that resides at Gmail, Google Apps or another kind of mail provider.

Method 2: “Client to Server” (Push migration)

The “Client mail Migration” is based on a concept in which the “source” (client or other source that has the mailbox data) is “pushing” the data into the Exchange Online mailbox.

An example for this method could be migration that describes as “PST migration”. When using this option the user is “responsible” for exporting the mailbox data to a PST file and then move\copy the data to the Exchange Online mailbox.

Additional example could be – the Microsoft tool: PST Capture that holds many users PST files in a central location and then can “push” the data to Exchange Online.

Some of the third party mail migration tools are based on this concept. The mailbox data is copied from the organization’s mail server into a central location (the migration stations) and “push” by the migration station to Exchange Online.

1. Office 365 built-in migration tools

Office 365 includes built-in mail migration tools (Native Office 365 mail migration tools) that was designed for different needs and different organization mail infrastructure.

The Office 365 built-in mail migration tools are:

• Cutover migration
• Stage migration
• IMAP Migration
• Hybrid migration

Native Office 365 mail migration tools | basic concepts

In the following section, I would like to review some basic terms\concepts that relate to mail migration when using the Native Office 365 mail migration tools.

Public presence

To be able to use the native Office 365 mail migration tools, the Exchange on-Premise server must have a “public presence” (Public IP, Public certificate, etc.). An additional requirement is that the Exchange on-Premise server will be configured for providing an Outlook AnyWhere service
(the former term is RPC/HTTPS).

The need for “Public presence” is a mandatory requirement because when using the Native Office 365 mail migration tools, the mail migration process is implemented by the Exchange Online that “build” a communication channel to the Exchange Online that use for the mail migration process.

The “Public presence” of Exchange on-Premises server is needed for additional scenarios such as Hybrid configuration. Besides of the subject of “mail migration”, Hybrid configuration defines a “relationship” between the Exchange on-Premises server and Exchange Online that is used for additional services such as: Mail flow, Free\Busy time and much more.

Migration batch
The mail migration is implemented by creating a new migration batch form the Exchange Online web management console. The migration batch is a logical concept that serves for holding information about:

• The names of the mailbox that we want to migrate
• The information about the “end point”
• A location for saving and presenting mail migration logs and information about the mail migration process

One exception for the concept of “information about the names of the mailboxes that we need to migrate” is when we use the option of Cutover migration. This type of mail migration is based on the basic assumption that we need\want to migrate 100% of the mailboxes.

End Point
The “initialization” of the migration process, is implemented by creating a logical connector from the Exchange Online that described as “End Point”. The end point is just a configuration file that includes the following details:

• The required credentials (administrative user name and password) that will be used by the Exchange Online when he connects to the “mail server” (Exchange on-Premises server or other mail server).
• The name of the domain and the mail server name. (In case that the server is Exchange on-Premises server, the domain name will be used in the AutoDiscover process).
• The value of the maximum concurrent sessions (the maximum number of concurrent mailbox migration).

In the following screenshot we can see the setting of the “End point”

Mail migration | Copy verses Move

An additional classification that we can define, is related to the process of copy mailbox data to Exchange Online versus the process of “move mailbox data” to Exchange Online.
Cutover migration and stage migration methods will only copy the mailbox data to Exchange Online versus the Hybrid migration method, that moves the Exchange on-Premises server mailbox content to the cloud (after a successful migration process the mailbox will be deleted from the Exchange on-Premises server database).

Hybrid migration verses Cutover and Stage mail migration | total amount of data

In this section, I would like to highlight a very important issue that relates to the “amount of the data” that is involved in the mail migration process, when using Native Office 365 mail migration tools.

Most of the time, when we talk about the issue of mail migration to the cloud, we relate to the “amount of data” that we need to “transfer” from point A (the organization’s network most of the time) to point B (Office 365\Exchange Online).

A very important detail that is neglected most of the time, is the amount of data that we “sent back” from the cloud – to the organization’s network (and will affect the network bandwidth of the organizational communication lines).
When talking about the Native Office 365 mail migration tools, we can classify the mail migration options to two groups: Cutover, Stage and IMAP migration versus Hybrid migration.

Cutover, Stage and IMAP migration
When we perform mail migration using one of the following migration options: IMAP, Cutover and Stage migration, we need to calculate the amount of data that will traverse the organization communication line by using the following formula: Mailbox size X 2

The reason for this formula is that, in the first time, we need to migrate the existing mailbox content from the organization to the cloud.

In the following diagram, we see an illustration of scenario in which we migrate 15GB mailbox to the cloud (Exchange Online).

The detail that is not mentioned most of the time, is that when using IMAP, Cutover and Stage migration, the existing Outlook OST file is no longer valid.

After the migration process of a mailbox will successfully be completed, we will need to create a new Outlook mail profile. Because the Outlook client is configured to use the option of cache mode, that will lead to a creation of a new OST file (the “old OST” file will just reside in the user profile folder, and there is no way to use this file), and Outlook client will automatically start to “pull” the mailbox content from the Exchange Online mailbox to the local user desktop OST file.

In our scenario, the Outlook client will need to “pull back” the 15GB of data to the local OST file.

Hybrid migration
When using the option of Hybrid migration, we are avoiding from need to double the size of the mailbox data because, when using the option Hybrid migration, we use the term “Move mailbox” (instead the term of “Copy mailbox” when using IMAP, Cutover and Stage migration).

The mailbox content is “moved” from Exchange on-Premises server to the cloud and the Outlook client “know” how to use the existing OST file + update the existing Outlook mail profile that will point to the “new mail server” (to the name of the Exchange Online server. If we want to be more accurate, the name of the Exchange Online CAS server).

2. PST migration

Additional type of migration could be described as: “PST Migration”. I relate to this type of migration as “client side mail migration” because, the concept of PST migration is implemented by exporting the mailbox data to a PST file, create an Exchange Online mailbox and import the data from the PST file, into the Exchange Online mailbox.

I cannot refrain from expressing my opinion about PST migration. My recommendation is to try to avoid from this type of migration because, I think that this migration type is not effective and include a couple of major disadvantage’s verse the more optimal methods such as using the Office 365 built-in mail migration tools.

When using the option of PST migration, the data is “push” to Exchange Online mailbox from the user desktop. Its truth that PST Migration doesn’t need to double the size of the data by copy the data to the cloud and copy again the data form the Exchange Online to the user desktop (the method that is used when using Cutover and Stage migration) but, the process of exporting the data from Outlook and importing back the data to the user desktop + synchronizing the data to the Exchange Online mailbox is quite tedious, prevent from the user to access his mailbox as long is the export\import process is implemented and complicate the mail migration process because the person that is implementing the mail migration, will need to access separately each of the user desktops for creating the mail migration procedure.

3. 3rd Party Migration

I will not go into details regarding the subject of: 3rd Party Migration tolls\software because of the simple reason that I don’t have a lot of experience with 3rd Party mail migration tolls. Generally speaking, 3rd Party Migration tools can implement the mail migration process to Exchange Online, by using the following methods:

• MAPI Migration (for my opinion, a More suitable term is RPC/HTTPS, but this is a term that mentioned in the Microsoft article).
• EWS Migration
• PST migration

Organization mail server technology

Microsoft Native Office 365 mail migration tools, was designed to provide a solution that is based on the basic assumption that – the organization’s mail server is a “Microsoft Exchange server.”

In the real life, there are many other mail servers such as: IBM lotus notes, Novell GroupWise and more. In these scenarios, most of the time, the only option is to purchase 3rd Party Migration product and, usually, 3rd Party mail Migration products, has additional enhancement and features that isn’t included in the Native Office 365 mail migration tools.

Scenario 1: 3rd Party mail Migration products using an “external component”
in this scenario the mail migration is implemented by using an “external component” that has two logical connectors. One connector is connected to the organization’s mail server (Microsoft Exchange on-Premises server or other mail server) and the other “leg” is connected to the Exchange Online. The 3rd Party mail migration component is responsible for “pulling” the data from the organization’s mail server and “transfer” the data (mailbox content) to Exchange Online.

Scenario 2: “Migration server“
The second methodology that is implemented by 3rd Party mail migration products described (by Microsoft) as a: “Migration server” or “jump box”. The Migration server becomes the “hub” of the migration process.

The mail server mailbox data is “transferred” to the Migration server who “hold and manage” the data and use a connector to the Exchange Online that will use for “transferring” the data to the cloud.

Exchange and the Migration engine

When we are relating to mail migration from Exchange server, there are a couple of methods that we can use for communication with the Exchange server and asking to “pull out” the data (user’s mailbox content). The available options are:

• RPC/HTTPS
• HTTPS/EWS
• IMAP

RPC\HTTPS and EWS

The “communication channel” that is created between the Exchange Online sever and the Exchange On-Premise is implemented by using the HTTPS protocol.

To be able to simplify the concept of RPC\HTTPS and EWS we can relate to this method as “Exchange listeners” the way the Exchange server “listen”, provide services and communicate with other hosts such as: Mail client (Outlook AnyWhere) or other servers  (in our scenario Exchange Online).

The Exchange EWS (Exchange Web services) method is more advanced and effective, and when relating to the subject of mail migration from Exchange, this is the preferred (if passable) method.

Exchange Web Service (EWS) is the recommended protocol to use for migrating to Office 365 because it supports large data batches and has better service-oriented throttling. In Office 365, when used in impersonation mode, migrations using EWS don’t consume the user’s budgeted amount of Office 365 EWS resources, consuming instead a copy of the budgeted resources:All EWS impersonating calls made by the same administrator account are calculated separately from the budget applied to this administrator account. For each impersonation session, a shadow copy of the actual user’s budget is created. All migrations for this particular session will consume this shadow copy. Throttling under impersonation is isolated to each user migration session.

In the following chart, we can see the three Exchange “listeners” that we can use for “puling” the mailbox data from the Exchange server.

Microsoft Native Office 365 mail migration tools and the communication with Exchange on-Premises server

When we use the Microsoft Native Office 365 mail migration tools for “pulling” data from Exchange on-Premises server, the communication with the Exchange on-Premises server “listeners” will be implemented as follows: Cutover and Stage migration, will communicate with the Exchange on-Premises server using RPC, or if we want to be accurate: RPC/HTTPS (the real layer structure is actually MAPI/RPC/HTTPS).

Hybrid migration considers as more sophisticated because, the communication with the Exchange on-Premises server is implemented by addressing the “EWS listener” and by using a built-in component named MRS proxy, who is responsible for handling and managing the move mailbox requests (from the Exchange on-Premises server\s to the Exchange Online in our scenario).

When the mail migration is implemented by using the Exchange EWS, the result of the mail migration throughput is better than the “other” methods such as RPC and IMAP because the Exchange EWS was designed to handle a large amount of data and multiple connection in an optimal way.

In the following diagram, we can see the how different mail migration option is the Exchange “listeners” for implementing mail migration. When using a Third party mail migration product, it’s recommended to ask the provider about the specific method (RPC, EWS and so on) that the product use.

A quick reference for the article series

	Mail migration to Office 365| Factors that impact mail Migration throughput | Part 2/4 The second article includes a review the different factors that impact the performance of the mail migration throughput.
	Mail migration to Office 365| Optimizing the Mail Migration throughput | Part 3/4 The third article recommendation and best practices for improving and optimize the performance of the mail migration throughput.
	Mail migration to Office 365 | Measure and estimate Mail Migration throughputs | Part 4/4 The last article in this series is dedicated to information about the “expected mail migration throughput” and includes a nice Excel based utility (Office 365 – Multiple and Single Mailbox Migration throughput calculator) that will help us to provide an estimation for the expected data transfer rate. Based on this information we can provide a reasonable “end date” for the completion of the mail migration project.

Additional reading

• Exchange RPC and EWS Protocol Test Suites
• Error message when you try to migrate users from an on-premises Exchange Server environment to Exchange Online in Office 365: “Unable to connect to the server
• How to migrate mailbox data by using the Exchange Admin Center in Office 365
• Migrate Mailboxes to the Cloud with a Staged Exchange Migration