Mail migration to office 365 mail migration methods - part 1#4

of 21 | Mail migration to Office 365 | Mail Migration methods | Part 1/4
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Mail migration to Office 365 | Mail
Migration methods | Part 1/4
The subject of: mail migration to Office 365 includes many aspects such as:
 Choose the suitable migration planmethod, 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 toolsmethods 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.
1. Microsoft Office 365 built-in mail migration tools
2. Third party mail migration tools

3. 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 “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
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 basic, 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 movecopy 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 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.
Note – the term “Migration to Office 365” relates to additional aspects such as user
migration, but, in this article, we relate only to the part of “mail migration”
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 termsconcepts 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,
FreeBusy time and much more.
Migration batch
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 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 needwant 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 365Exchange 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, this
migration type is not effective and include a couple of major disadvantages 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 “pushed” 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 from the
Exchange Online to the user desktop (the method that is 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 exportimport
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.
Note – there is an option for implementing PST migration in a more “centralized
way” by using a free Microsoft utile named: PST capture.
You can download the PST capture tool form 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 toolssoftware
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 is based on the basic assumption that – the organization’s mail server is a
“Microsoft Exchange server.”
Note – The exception for this concept is, the IMAP mail migration method, which
enables us to implement mail migration form mail server the support the IMAP4
protocol and doesn’t have to be 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.

Note – regarding the issue of “double the mailbox data” that is 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 is 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 asking
to “pull out” the data (user’s mailbox content). The available options are:
 RPC/HTTPS

 HTTPS/EWS
 IMAP
Note – I will not relate to the IMAP migration method basic assumption is that this
method will be used for mail migration from non-Exchange servers.
RPCHTTPS 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 RPCHTTPS 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.
[Source of information: Exchange Online Migration Performance and Best
Practices ]
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 servers 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 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.
Additional reading
 How to migrate mailbox data by using the Exchange Admin Center in Office
365
 Ways to migrate multiple email accounts to Office 365

Mail migration to office 365 mail migration methods - part 1#4

More Related Content

What's hot (17)

Viewers also liked (14)

Similar to Mail migration to office 365 mail migration methods - part 1#4 (20)

More from Eyal Doron (20)

Recently uploaded (20)

Mail migration to office 365 mail migration methods - part 1#4