Mail migration to Office 365 | Mail Migration methods | Part 1/415 min read
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).
Mail migration to Office 365 | Optimizing the Mail Migration throughput | The article series
The article series includes the following articles:
- Mail migration to Office 365 | Mail Migration methods | Part 1/4
- Mail migration to Office 365 | Factors that impact mail Migration performance | Part 2/4
- Mail migration to Office 365 | Optimizing the Mail Migration throughput | Part 3/4
- Mail Migration to Office 365 | Measure and estimate Mail Migration throughputs | Part 4/4
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.
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.
- Microsoft Office 365 built-in mail migration tools
- Third party mail migration tools
- PST migration
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.
The exception to the rule that the “target 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 in Gmail, Google Apps or another kind of mail provider.
Note – although we can use IMAP protocol for performing mail migration from Exchange server, this option is not recommended because the IMAP protocol is very limited and necessary, and he doesn’t know how “deal” with many types of data that exists in the Exchange user mailbox.
My opinion is that the only time we will use the option of “IMAP mail migration” is only when we don’t have any other choice. For example: implementing a mail migration project when the “source mail server” is not Exchange server, but instead a “standard mail server” and the only option for “pulling the data” from this server is by using the IMAP protocol.
Method 2: “Client to Server” (Push migration)
The “Client mail Migration” is based on a concept in which the “source” (client or another source that has the mailbox data) is “pushing” the data into the Exchange Online mailbox.
An example of 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.
An 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 based on this concept. The mailbox data 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.
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 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 uses for the mail migration process.
The “Public presence” of Exchange on-Premises server 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 used for additional services such as – Mail flow, Free\Busy time and much more.
The mail migration is implemented by creating a new migration batch from 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 to 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 based on the underlying assumption that we need\want to migrate 100% of the mailboxes.
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 username and password) that will be used by the Exchange Online when he connects to the “mail server” (Exchange on-Premises server or another 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 “Endpoint.”
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, which 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 versus Cutover and Stage mail migration | total amount of data
In this section, I would like to highlight an imperative 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 paramount detail that 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 the scenario in which we migrate 15GB mailbox to the cloud (Exchange Online).
The detail that 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 was successfully 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.
When using the option of Hybrid migration, we are avoiding from the 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 current 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
An additional type of migration could describe as: “PST Migration”. I relate to this type of migration as “client side mail migration” because the concept of PST migration 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 this type of migration because this migration type is not valid and include a couple of significant disadvantages verse the most optimal methods such as using the Office 365 built-in mail migration tools.
When using the option of PST migration, the data is “pushed” to Exchange Online mailbox from the user desktop. It’s 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 from the Exchange Online to the user desktop (the method that used when using Cutover and Stage migration).
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 complicates the mail migration process because the person that is implementing the mail migration, will need to access each of the user desktops separately for creating the mail migration procedure.
You can download the PST Capture tool from the following link: Microsoft Exchange PST Capture 2.0
3. 3rd Party Migration
I will not go into details regarding the subject of 3rd Party Migration tools\software because of the simple reason that I don’t have a lot of experience with 3rd Party mail migration tools. 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 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 aren’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 connected to the organization’s mail server (Microsoft Exchange on-Premises server or another 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 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.
Note – regarding the issue of “double the mailbox data” that caused by the need to copy the mailbox content from the organization mail server to the Exchange Online mailbox and back.
When Outlook will “Pull back” the data from the Exchange Online mailbox to the local OST, it looks to me that most of the 3rd Party mail migration products will not have the ability to use the local Outlook OST file (the method that implemented by using the Hybrid migration) but the best practice is asking the software providers about this option.
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 ask to “pull out” the data (user’s mailbox content). The available options are:
RPC\HTTPS and EWS
The “communication channel” that created between the Exchange Online server and the Exchange On-Premise 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 efficient, and when relating to the subject of mail migration from Exchange, this is the preferred (if passable) method.
[Source of information: Exchange Online Migration Performance and Best Practices ]
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 a copy of the budgeted resources instead: 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 “pulling” 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 implemented by addressing the “EWS listener” and by using a built-in component named MRS proxy, who is responsible for handling and managing the mailbox move requests (from the Exchange on-Premises server\s to the Exchange Online in our scenario).
When the mail migration 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 connections in an optimal way.
In the following diagram, we can see how the different mail migration options use 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.
It is important for us to know your opinion on this article