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 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

http://o365info.com/mail-migration-office-365-mail-migration-methods-part-14/

https://il.linkedin.com/in/eyaldoron1

http://o365info.com/


http://o365info.com/mail-migration-office-365-factors-impact-mail-migration-throughput-part-24/

http://o365info.com/mail-migration-office-365-factors-impact-mail-migration-throughput-part-24/



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.

1. Microsoft Office 365 built-in mail migration tools

2. Third party mail migration tools




http://o365info.com/mail-migration-office-365-optimizing-mail-migration-throughput-part-34/

http://o365info.com/mail-migration-office-365-optimizing-mail-migration-throughput-part-34/

http://o365info.com/mail-migration-office-365-measure-estimate-mail-migration-throughputs-part-44/

http://o365info.com/mail-migration-office-365-measure-estimate-mail-migration-throughputs-part-44/



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 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 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 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 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 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, 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 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.

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 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




http://www.microsoft.com/en-us/download/details.aspx?id=36789

http://www.microsoft.com/en-us/download/details.aspx?id=36789



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.

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.

[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.




http://technet.microsoft.com/library/dn592150(v=exchg.150).aspx

http://technet.microsoft.com/library/dn592150(v=exchg.150).aspx



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 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




http://support.microsoft.com/kb/2798131/en-gb

http://support.microsoft.com/kb/2798131/en-gb

https://support.office.com/en-gb/article/Ways-to-migrate-multiple-email-accounts-to-Office-365-0a4913fe-60fb-498f-9155-a86516418842?ui=en-US&rs=en-GB&ad=GB

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

Documents