Mailbox Migration Office 365: The Complete Guide

This post is about mailbox migration office 365 so we will focus only on Exchange Online and hybrid administration topics in this chapter.

Mailbox migration office 365 options

There are three primary types of migration options:

• Cutover migration
• Staged migration
• Hybrid deployment migration

Cutover migration

A cutover migration is ideal for organizations with 1,000 mailboxes or less. The other important requirement for a cutover migration is that directory synchronization has not been established. The reason for this is because the cutover migration will create users in Office 365 as part of the process. Therefore, if directory synchronization is already synchronizing Active Directory (AD) objects to Office 365, you need to use a staged migration or migrate using a hybrid deployment. You must disable directory synchronization if you would like to do a cutover migration.

Before we look at how a cutover migration is set up, it is useful for you to know what happens when you execute a cutover migration. When a cutover migration is initiated, the following processes occur:

• The migration service provisions new mailboxes in Exchange Online by reading the on-premises Exchange 2003 or 2007 address book.
• On-premises distribution groups and contacts are migrated to Exchange Online.
• The migration service then migrates the contents, contacts, and calendar items from on-premises mailboxes to their corresponding online mailboxes. This part of the process is called initial synchronization.
• On-premises mailbox contents are synchronized with their corresponding online mailboxes every 24 hours. This part of the process is called incremental synchronization.
• When you are ready to complete the migration, change the MX record to start routing emails to the online mailboxes and end the migration. Exchange will conduct a final synchronization and notify the administrator through email that the migration is complete.

The email notification will contain two reports:

• MigrationErrors.csv — This report contains a list of mailboxes that failed to migrate and information about the error.
• MigrationStatistics.csv — This report contains a list of mailboxes and the corresponding number of items migrated. The report also includes a unique password assigned to each mailbox that the user will need to change after the initial log on. Remember that this is because the cutover migration creates new accounts as part of the migration process.

Cutover migration with EAC

If your organization is using the latest release of Office 365, the ECP will not be an available graphical user interface (GUI) option. Instead, you will use the EAC. To initiate a cutover migration using the EAC, follow these steps:

• Access the Microsoft 365 admin center
• After authentication, select Exchange from the Admin centers

• In the EAC, expand Migration on the pane on the left and select Batch and then click the New migration batch.

• Enter a name for the cutover migration and select Select Migrate to Exchange Online as a migration path and then click Next.

• Select the migration type as cutover migration

• Prepare for a cutover migration provides the prerequisite steps for cutover migration. Read it to learn how to migrate mailboxes using this migration type. After prerequisite meets, click Next.

• Select a migration endpoint. They are connection settings for the server that you want to migrate users to or from. They can be associated with any migration batch. Select or create the migration endpoint describing the connection to the remote environment. Learn more about migration endpoints.

• To carry out a migration, a .csv file is required which containing the attributes of mailboxes you want to migrate. The first row of the .csv file is the header row and should contain only the following attribute names:

EmailAddress: This is the SMTP address of the mailbox and is the only required attribute.

Password: The password that will be set for the cloud-based mailbox after it is migrated. This is an optional attribute and is not required if single sign-on (SSO) is enabled. If you set the password in the .csv file and SSO is enabled, it will be ignored. Simply leave this box blank if it does not apply to your configuration.

ForceChangePassword: This Boolean attribute specifies whether the user must change the password when first logging on to the cloud mailbox. The value is either True or False. This is also an optional attribute and is not required if SSO is enabled. If you set this attribute in the .csv file and SSO is enabled, it will be ignored. Simply leave this box blank if it does not apply to your configuration.

• This .csv file will cause the staged migration process to migrate five mailboxes, set the password for the new cloud mailboxes to NewPa$$word, and require only Mike and Scott to change their password upon initial logon to their respective cloud mailboxes.

• The .csv file can contain only these attributes.

• Next, select a target domain and specify bad item limit and large item limit if needed.

• Choose to either manually or automatically start the migration and provide email addresses that a report should be sent to after the migration is complete.

• Allow for a few minutes to begin the migration.

Staged migration

A staged migration is a process where a subset of mailboxes and content is migrated in several batches over time and applies only to Exchange 2003 and 2007. A staged migration is typically the approach if you have more than 1,000 mailboxes. Special consideration for staged migration is that you need to identify mailboxes that must be in the same migration batch. The mailboxes of individuals participating in delegate permissions must be kept together. Therefore, they need to belong to the same batch when you plan a staged migration. A staged migration is the appropriate migration method if directory synchronization is already implemented.

Before we examine how to set up a staged migration, it is useful for you to know what happens during a staged migration. When you initiate a staged migration, the following processes occur:

• The migration service checks that directory synchronization is configured, prompts for the .csv file, and checks that each entry in the .csv file is a mail-enabled user (MEU) in Office 365.
• The service then converts the MEUs into mailboxes and populates the TargetAddress property of the on-premises mailbox with the email address of the cloud mailbox.
• After the TargetAddress property has been updated for all mailboxes, you will receive an email with a list of mailboxes that have been successfully created and converted. Mailbox contents are not migrated yet, but the users can start using the mailbox without any MX record changes. This is because if emails arrive at the on-premises mailbox, they will be redirected to Exchange Online because of the TargetAddress property.
• The migration service then starts to migrate the contents, contacts, and calendar items from the on-premises mailboxes to their corresponding online mailboxes. When content migration is done, another report is emailed to administrators.
• At this point, you can create and start additional migration batches.
• When you are done with the migration, change the MX records so that email will be directly delivered to the online mailboxes. You can then complete the migration. The migration service will carry out any necessary cleanup and checks to make sure every MEU that has a corresponding on-premises mailbox has been migrated. A final status report will then be sent to the administrator.
• Select a migration type to Staged migration

• Prepare for a staged migration provides the prerequisite steps for a staged migration. Read it to learn how to migrate mailboxes using this migration type.

• It is similar to a cutover migration except that you have to change a migrate type and prerequisite. As such, we will not be covering the steps again here.

Hybrid deployment migration

Migration after establishing an Exchange hybrid environment is one of the most popular approaches because, unlike the other methods we have covered so far after you establish an Exchange hybrid environment, you can move mailboxes to the cloud and back to on premises. Part of setting up an Exchange hybrid environment is to implement an Exchange 2010 Service Pack 3 (SP3) Client Access Server (CAS). This introduces the Mailbox Replication Service (MRS) that comes with the 2010 SP3 CAS. MRS is the service responsible for carrying out mailbox moves.

• If your organization has Exchange 2010 and later versions with more than 1,000 mailboxes, you will need to implement an Exchange hybrid deployment.

• Prepare for a remote move migration provides the prerequisite steps for a remote migration. Read it to learn how to migrate mailboxes using this migration type.

• You have an ability to choose users manually instead of a csv file for remote move migration.

• Remaining steps are similar to a cutover migration. As such, we will not be covering the steps again here.

Third-party migration tools

If for some reason the existing tools and options provided by Microsoft do not meet your migration needs, there are always third-party tools you can turn to. Examples of third-party Exchange migration tools are Quest Software, Binary Tree, BitTitan, Cemaphore, and Metalogix. Exchange is a mature platform and has been around for some time. Therefore, thirdparty tools are readily available and are just as mature.

Migration best practices

There are several best practices when migrating mailboxes. We will list some of the common ones you should consider adopting when migrating mailboxes from on-premises mail servers to Exchange Online.

Reduce the TTL for MX records

In most scenarios, you will want to route incoming email to Exchange Online. Therefore, before starting any of the migration tasks, regardless of whether it is a cutover, staged, or IMAP migration, change the Time To Live (TTL) of your MX records to improve the DNS convergence time when you do switch your MX records. The recommendation is that you change the TTL to 3,600 seconds, which is one hour.

Migration performance

• Many factors affect migration performance, such as the size and number of items in the mailboxes, network bandwidth, network latency, and the on-premises mail servers.
• Migration performance can also be affected by the time of day and the number of users on the network. That is why you should carry out migrations after the workday is done or over weekends.
• As an example, after initial tests with a small staged migration batch, Microsoft Consulting Services generally aims to ramp up to a migration rate of 1,000 mailboxes a week, mostly conducted after business hours when network utilization is at the lowest level.
• Latency and sustained throughput are factors that are just as important when it comes to migration performance.

Migration service throttling

In the migration exercises that you looked at earlier in this chapter, recall that you have the ability to specify the number of mailboxes that are migrated simultaneously, which by default is three. Specifying the number of mailboxes that should be simultaneously migrated is referred to as migration-service throttling.

Refer again to the “Migration Performance” white paper or test a single mailbox migration to determine the migration throughput. This will help you determine the optimum number of simultaneous migrations your network can support.

User throttling

• User throttling mostly affects third-party migration tools. User throttling limits the number of mailboxes a user can access simultaneously and is designed to minimize risks and preserve resources.
• Therefore, if a migration tool uses a single service account with access to all mailboxes, Office 365 might throttle the service account if it starts to access too many mailboxes simultaneously during the migration process, thereby impacting migration performance.
• When you evaluate migration tools, make sure that performance will not be impacted by user throttling.
• Good migration tools generally use Exchange Web Services to impersonate user accounts so Exchange Online is not seeing a single user simultaneously accessing multiple mailboxes, but rather the users accessing their respective mailboxes. Thus, user throttling will not be triggered.

Moving mailboxes back to on-premises Exchange

• Moving mailboxes back to on-premises can be facilitated only through an Exchange hybrid environment.
• Otherwise, you will need to rely on third-party tools. Unlike having the cutover and staged migration options from the EAC when moving mailboxes to Office 365, there are no built-in options to carry out the reverse.
• As you saw, after you have implemented an Exchange hybrid environment, the move of a mailbox to Office 365 is done by carrying out a remote move request.
• To move mailboxes back on-premises, you need to take into consideration whether the mailboxes you want to move were created in Office 365 from the very beginning or whether they were first created on-premises and then moved to Office 365.

Mailbox originally created on-premises

If the mailbox you want to migrate from Office 365 was initially created on-premises and then migrated to the cloud, all you have to do is delete the batch created to migrate a mailbox to Exchange Online before you begin, otherwise, it will say it has migrated successfully but nothing will have been moved.

• Go to Exchange Admin Centre -> Recipients -> Migration
• Click on + and select ‘Migrate from Exchange Online’

• At ‘Select the users that you want to move’ and click on Add and search for a mailbox you want to migrate and then click Next.

• Select the migration endpoint and click Next.

• Confirm the migration endpoint and click Next.

• Enter a name for the migration and enter your tenant domain. For example, http://techiberry.onmicrosoft.com and select Move the primary mailbox and the archive mailbox if one exists and mention the target database and click Next.

• Click browse to have a report emailed to you when the migration has been completed and select ‘Automatically start the batch’ & ‘Automatically complete the migration batch’, click New

Mailbox originally created in Exchange Online

If the Exchange Online mailbox you want to move back to on-premises Exchange was originally created in Office 365, you will need to first set the ExchangeGUID property on the associated on-premises mailbox. You need to do this because the ExchangeGUID property is not synchronized back to the associated on-premises mailbox if the mailbox was initially created in Office 365. For a remote move request to succeed, the value stored in the ExchangeGUID property must be the same for the mailbox in Office 365 and the associated on-premises remote mailbox.

Follow these steps to check and set the ExchangeGUID property for the on-premises remote mailbox:

• Start the EMC on your on-premises Exchange hybrid server.
• Check if the ExchangeGUID property on the on-premises remote mailbox is set by entering the following command.

Get-RemoteMailbox “alias of cloud mailbox to migrate back on-premises” | Format-List ExchangeGUID

• If the return value for ExchangeGUID is not all zeros, then ExchangeGUID is set. You can immediately initiate a remote mailbox move back to on-premises Exchange by following the steps outlined in the “Mailbox originally created on-premises” section.
• If the return value for ExchangeGUID is all zeros, then ExchangeGUID is not set. Enter the following command to retrieve ExchangeGUID for the Exchange Online mailbox, and write down the returned value. Do not use the Exchange Management Shell.

Get-Mailbox “alias of the cloud mailbox to migrate back to on-premises” | Format-List ExchangeGUID

• Go back to the Exchange Management Shell window, and enter the following command to set the value of the ExchangeGUID property on the on-premises remote mailbox.

Set-RemoteMailbox “alias of cloud mailbox to move” -ExchangeGUID “paste the GUID of the Exchange Online mailbox”

• If the Exchange GUID fails to update, follow the steps mentioned here.
• Allow for a few hours to reflect these changes to office 365.
• After the sync is completed, you can follow the steps outlined in the preceding section to move the mailbox from the cloud back to on-premises.

Also Read: How To Migrate Skype Meetings To Teams?