Migrate a Subset of Mailboxes to the Cloud with a Staged Exchange Migration

Applies to: Office 365 for enterprises, Live@edu

Topic last modified: 2012-06-26

You can use the Email Migration dashboard in the Exchange Control Panel to migrate a subset of your on-premises mailboxes to the cloud. This process is called a staged Exchange migration. It allows you to move some mailboxes to the cloud while maintaining the rest of the mailboxes in your organisation's on-premises Exchange environment. You can also use this type of migration as an intermediate step to moving completely to a cloud-based Exchange organisation.

Important:

You can’t use a staged Exchange migration to migrate Exchange 2010 mailboxes. If you have fewer than 1,000 Exchange 2010 mailboxes in your organisation, you can use a cutover Exchange migration. If you have more than 1,000 Exchange 2010 mailboxes, you can implement a hybrid deployment. For more information, see the following:

Also, to use a staged Exchange migration, you have to replicate user objects from your on-premises Active Directory directory service to your cloud-based email organisation. Depending on your organisation type, you have to install and configure a directory synchronisation tool before you can run a staged Exchange migration:

Microsoft Office 365 for professionals and small businesses Staged Exchange migration isn’t available because Office 365 for professionals and small businesses doesn’t support directory synchronisation.

With a staged Exchange migration, you only migrate user mailboxes and resource mailboxes. Directory synchronisation replicates other recipient types, such as distribution groups, external contacts and mail-enabled users to your cloud-based organisation.

When you use a staged Exchange migration and CSV file to migrate on-premises Exchange mailboxes to the cloud, the migration service does the following for each migration batch that you run:

It verifies that OLSync or the Directory Synchronisation tool is enabled for your cloud-based organisation.

It checks that a mail-enabled user exists in the cloud-based email organisation for each entry in the CSV file.

It converts the mail-enabled user to a mailbox.

It configures mail forwarding by populating the TargetAddress property on the on-premises mailbox with the email address of the cloud-based mailbox. This enables email sent to an on-premises mailbox to be forwarded to the corresponding cloud-based mailbox.

It migrates email messages, contacts and calendar items from the Exchange mailboxes to the corresponding cloud-based mailboxes. After mailbox items are migrated, the Exchange and cloud-based mailboxes aren't synchronised. New email sent to the on-premises Exchange mailbox is forwarded to the corresponding cloud-based mailbox.

It sends an email message to the administrator when the migration batch is complete. This message lists the number of mailboxes that were successfully migrated and how many couldn’t be migrated. The message also includes links to migration statistics and error reports that contain more detailed information.

Before you begin

Be sure to plan your email migration carefully, especially verifying your ability to connect to your Exchange server. When you plan, check out Best practices.

Install and configure a directory synchronisation tool for your cloud-based organisation OLSync or the Directory Synchronisation tool must be running to perform a staged email migration. The directory synchronisation tool creates the mail-enabled users in your cloud-based organisation that are converted to mailboxes during the migration. If OLSync isn’t installed in your Microsoft Live@edu organisation, you can’t migrate mailboxes. If the Directory Synchronisation tool isn't installed in your Office 365 for enterprises organisation, you can only perform a cutover Exchange migration that migrates all your on-premises mailboxes to the cloud. For more information about the different types of migration, see Email Migration Overview.

For more information about how to install a directory synchronisation tool, see the following:

Plan for user identity management After your on-premises mailboxes are migrated to the cloud, the synchronisation process continues to update the user attributes on the mailbox according to changes made in the on-premises Active Directory. This means that “source of authority” for managing user objects is your on-premises directory, and that you can’t manage user mailbox properties in Exchange Online. However, after running a staged Exchange migration you can configure directory synchronisation so that the source of authority is the Office 365 directory, which allows you to manage mailbox properties in Exchange Online. For more information about user identity management after migrating mailboxes to Office 365, see the following:

Configure Outlook Anywhere on your on-premises Exchange server The migration service uses RPC over HTTP, or Outlook Anywhere, to connect to your on-premises Exchange server. For information about how to set up Outlook Anywhere for Exchange 2007 and Exchange 2003, see the following:

Important Your Outlook Anywhere configuration must be configured with a certificate trusted by a certification authority (CA). It can't be configured with a self-signed certificate. For more information, see How to Configure SSL for Outlook Anywhere.

Verify that you can connect to your Exchange organisation using Outlook Anywhere Try one of these methods to test your connection settings:

Use Microsoft Office Outlook from outside your corporate network to connect to Exchange.

Prepare the CSV file Identify the group of users whose on-premises mailboxes you want to migrate to the cloud. Include these users in the CSV file that will make up the migration batch. Mailboxes are migrated in the same sequence listed in the CSV file.

Important There is no limit for the number of mailboxes you migrate to the cloud using a staged Exchange migration. However, the CSV file for a migration batch can contain a maximum of 1,000 rows. To migrate more than 1,000 mailboxes, you have to submit additional CSV files.

Here are the required attributes for the mailboxes you want to migrate:

EmailAddress specifies the primary SMTP email address for the on-premises mailbox. This attribute is required.

Important Be sure to use the primary SMTP address for on-premises mailboxes and not user IDs from the cloud-based organisation. For example, if the on-premises domain is named tailspintoys.com but the cloud-based email organisation is named service.tailspintoys.com you would use the tailspintoys.com domain name for email addresses in the CSV file.

Password is the password that will be set on the new cloud-based mailbox. This attribute is optional.

ForceChangePassword specifies whether a user must change the password the first time they sign in to their new cloud-based mailbox. Use either True or False for the value of this parameter. This attribute is optional.

Important If you’ve implemented a single sign-on solution by deploying Active Directory Federation Services 2.0 (AD FS 2.0) in your on-premises organisation, you must use False for the value of the ForceChangePassword attribute.

Here's an example of the format for the CSV file. In this example, three on-premises mailboxes are migrated to the cloud.

Assign the migration administrator permissions to access mailboxes in your Exchange organisation The on-premises account that you use to run the migration must have the necessary permissions to access all user mailboxes. You can assign the Full Access permission for individual mailboxes or assign the Receive As permission for a mailbox database. For more information, see the following.

Add your Exchange organisation as an accepted domain of your cloud-based email organisation The migration service uses the SMTP address of your on-premises mailboxes to create the email address for the new cloud-based mailboxes. If you are a Live@edu organisation, migration will fail if your Exchange domain isn't an accepted domain (or the primary domain) of your cloud-based organisation. For more information, see the following topics:

Disable unified messaging If the mailboxes you are migrating are enabled for unified messaging (UM), you have to disable UM on the mailboxes before you migrate them. You can then enable UM on the mailboxes after the migration is complete. For more information, see Plan to Migrate UM-Enabled Mailboxes.

Exchange 2007 and later versions - Automatically detect connection settings with Autodiscover Select this option if you want the migration service to automatically connect to your on-premises Exchange server using the Autodiscover service.

Exchange 2003 and later versions - Manually specify connection settings Select this option if your on-premises messaging system is running Exchange 2003 or if you are running a later version but want to manually provide the connection settings to your on-premises mail server.

Click Next after you select a migration type.

Step 2 Configure the connection settings

Provide the credentials and connection settings for your on-premises Exchange server depending on the migration type that you selected. Perform only one of the following tasks based on your migration type.

Automatically detect connection settings with Autodiscover

If you selected this migration type, configure the migration to use the Autodiscover service to detect the connection settings. The connection settings you configure will persist on this page the next time you start Email Migration to create a new migration batch.

In this field…

Do this…

* Migration administrator email address

Type the email address for an administrator account that has access to your Exchange server and all mailboxes.

* Domain\Username

Type the username for the migration administrator account. Use the Domain\Username or UPN format.

* Password

Type the password for the migration administrator account.

Number of mailboxes to migrate simultaneously

Specify the number of connections to the Exchange server available to migrate mailboxes to the cloud. If the value is set to 3, the default value, you can migrate up to three mailboxes at the same time until all the mailboxes in the migration batch have been migrated. The maximum number of connections is 50. To learn more about how to optimise this setting, see Maximum Number of Connections to Your Mail Server.

If the test connection isn't successful, you are prompted to manually specify the connection settings. You have to connect to the Exchange server to continue.

If you can’t connect to your on-premises Exchange server, see this video for troubleshooting tips.

When the test connection to the Exchange server is successful, the Specify what and how to migrate (Step 2 of 3) page is displayed.

Manually specify connection settings

If you selected this migration type, provide the connection settings to your Exchange server.

In this field…

Do this…

* Domain\Username

Type the username for the migration administrator account. Use the domain\username format.

* Password

Type the password for the migration administrator account.

* Exchange server

Type the FQDN of the on-premises Exchange server. For example, EXCH-MSG-1.tailspintoys.com.

* RPC proxy server

Type the FQDN of the RPC proxy server for the on-premises Exchange server. For example, mail.tailspintoys.com.

Authentication

Select the authentication method used by the Exchange server. Options are Basic, the default, or NTLM.

Number of mailboxes to migrate simultaneously

Specify the number of connections to the Exchange server available to migrate email to cloud-based mailboxes. If the value is set to 3, the default value, you can migrate up to three mailboxes at the same time until all the mailboxes in the migration batch have been migrated. The maximum number of connections is 50. To learn more about how to optimise this setting, see Maximum Number of Connections to Your Mail Server.

Click Next. Microsoft Exchange tries to communicate with the on-premises Exchange server to verify the manual connection settings. If the test connection isn't successful, you'll be asked to verify the connection settings. You have to connect to the Exchange server to continue.

If you can’t connect to your on-premises Exchange server, see this video for troubleshooting tips.

If the test connection is successful, the migration service verifies that either OLSync or the Directory Synchronisation tool is enabled for your organisation, and then displays the Specify what and how to migrate (Step 2 of 3) page.

Note If the Directory Synchronisation tool isn't enabled for your organisation, you won’t be prompted to upload a CSV file. Instead, the migration process will attempt to perform a cutover Exchange migration. If you want to perform a staged Exchange migration, you have to cancel the migration, activate and install the Directory Synchronisation tool and then restart Email Migration.

Step 3 Upload the CSV file and name the migration batch

Click Browse to select the CSV file for the migration batch.

In the Batch name field, type a name that identifies the migration batch. This name is displayed in the Email Migration dashboard. Batch names can’t contain spaces or special characters.

To send copies of the migration reports to other users, click Browse at the bottom of the page.

If the CSV file successfully passes these checks, the migration batch is created and the Migration batch created successfully (Step 3 of 3) page is displayed.

Review the information about the migration batch, and then click Close.

Step 4 Start a migration batch

After you create a migration batch, it’s displayed in the list on the Email Migration dashboard. Details about the selected migration batch are displayed in the details pane. The status of the migration batch is set to Created.

To start processing a migration batch, select it and then click Start.

What happens after you start the migration batch?

After you start the migration batch, the status displayed in the details pane in the Email Migration dashboard is changed to Queued or Running. As previously mentioned, mailboxes are migrated in the same sequence as they’re listed in the CSV file.

The following table describes the information displayed in the details pane for the selected migration batch.

Field

Description

Status

The current state of the selected migration batch. Includes the following states:

Created Indicates that the migration batch is created. In this state, you can start, edit, delete or change its position in the migration queue using or .

Queued Indicates that the migration batch has been started. If the migration batch is at the top of the queue, it will start to run. If there are migration batches above it in the migration queue, the migration batch will remain in a queued state. It will start running after all migration batches above it are completed. In this state, you can stop the migration batch or change its position in the migration queue using or .

Running Indicates that mailboxes in the migration batch are being actively migrated. In this state, you can stop the migration batch.

Stopped Indicates that the migration batch is stopped and no more mailboxes from the batch are being migrated. In this state, you can re-start the migration batch.

Synced Indicates that migration batch is completed, and no mailboxes are being migrated. A migration batch in this state may contain errors when mailboxes weren’t migrated.

Requested

The number of mailboxes to be migrated in the migration batch. This number corresponds to the number of rows in the migration CSV file.

Synced

The number of mailboxes from the current migration batch that have been created in your cloud-based organisation. This field is updated during the migration.

Active

Specifies the number of mailboxes being actively migrated. This number corresponds to the number of mailboxes to migrate simultaneously that you specified when configuring the connection settings.

This section of the details pane contains links to the migration statistics and error reports. Links to these reports are sent to the administrator after the migration is complete.

Click Success or Errors to download the following reports:

MigrationStatistics A CSV file that contains a row for each mailbox that was successfully migrated. Each row contains the email address of the mailbox, the status of the migration, the number of mailbox items migrated and the number of mailbox items that were skipped and not migrated.

MigrationErrors A CSV file that contains a row for each mailbox that wasn't migrated or configured for mail forwarding. Each row contains email address of the mailbox and a description of the error.

Monitor a migration batch

Use the Email Migration dashboard and the per-user migration statistics to monitor the status of a migration batch that is actively running. For more information, see the following:

If you’ve started a migration batch and it has a status of Queued or Running, you can stop it. To stop a migration batch, select it and then click Pause. When you stop a migration batch that was queued, it will not start when the previous migration batch has finished running.

When you stop a migration batch that is running, any mailbox currently being processed is stopped immediately and isn't completed. Stopping a migration batch won't affect mailboxes that have been migrated already.

When you stop a migration batch that was running, you receive a status email message that says how many mailboxes were successfully created in the cloud before the batch was stopped and how many mailboxes weren’t migrated. This message also contains links to the statistics report, which lists the mailboxes that were successfully migrated and to the error report, which lists the mailboxes that weren’t migrated.

Restart a migration batch

You can restart a migration batch that was stopped or a migration batch that has finished running but which had errors resulting in mailboxes not being migrated.

To restart a migration batch, select it and then click Resume.

Step 5 Convert on-premises mailboxes to mail-enabled users

After a migration batch is finished running and you’ve verified that all mailboxes in the batch are successfully migrated and the initial synchronisation of mailbox items to the cloud is complete, we recommend that you convert the on-premises mailboxes in the migration batch to mail-enabled users. Why? After a staged Exchange migration, a user has an on-premises mailbox and a cloud mailbox. Because mail sent to the user’s on-premises mailbox is forwarded to their cloud mailbox after migration, users need to connect to their cloud mailboxes to access their email. But if a person uses Microsoft Outlook to open their mailbox, the Autodiscover service still tries to connect to the on-premises mailbox. After you convert on-premises mailboxes to mail-enabled users, the Autodiscover service uses the mail-enabled user to connect Outlook to the cloud mailbox after the user creates a new Outlook profile.

Another important reason to convert on-premises mailboxes to mail-enabled users is to retain proxy addresses from the cloud-based mailboxes by copying proxy addresses to the mail-enabled user. This lets you manage cloud-based users from your on-premises organisation by using Active Directory. Also, if you decide to decommission your on-premises Exchange organisation after all mailboxes are migrated to the cloud, the proxy addresses you’ve copied to the mail-enabled user will remain in your on-premises Active Directory.

For more information and to download scripts that you can run to convert mailboxes to mail-enabled users, see the following:

If there are errors in a migration batch or you want to migrate additional on-premises mailboxes to the cloud, you can create and start a new migration batch. To create a new migration batch, you have to submit a new CSV file that contains the information about the mailboxes you want to migrate. You can create and start a maximum of 100 migration batches. If a migration batch is currently running when you start another migration batch, the status for the newly started batch is set to Queued.

You don't have to enter connections when you start a new migration batch because they persist from the previous batch. When you create a new migration batch, the migration service connects to your on-premises Exchange server and verifies that OLSync or the Directory Synchronisation tool is still installed and running. When this query is complete, the migration service prompts you to select the CSV file.

After additional migration batches are complete and you verify that all mailboxes and mailbox items were successfully migrated, be sure to complete step 5 and convert the on-premises mailboxes in the migration batch to mail-enabled users.

Edit and re-start a migration batch to fix errors

You can edit an existing migration batch, submit a revised CSV file for the migration batch, and then re-start the migration batch. This is a good way to fix any migration errors that occurred the previous time the migration batch ran. Use the failure description from error reports to fix errors, such as on-premises mailboxes that can't be found using the SMTP address, before you resubmit a CSV file.

Here's how the migration service handles the migration requests when you edit and re-start a migration batch:

If a row in the CSV file corresponds to a mailbox that has been migrated successfully in a previous migration batch, it will reconfigure mail routing by resetting the TargetAddress property on the on-premises mailbox.

If a row in the CSV file failed in a previous migration batch, the migration service will try to migrate it again and pick up from the point where the previous failure occurred. For example, if there was a failure during the data migration stage, the migration service will try to migrate the data again. If it failed when it configured mail forwarding by setting TargetAddress property on the on-premises mailbox, it will try to reset the property and, if successful, will then start the data migration stage.

If a row in the CSV file doesn’t correspond to any of the mailboxes that have been migrated, it converts the mail-enabled user to a new cloud-based mailbox, configures mail forwarding and then migrates the mailbox data.

After all mailboxes in a migration batch have been successfully migrated and you have converted the on-premises mailboxes in the batch to mail-enabled users, you can delete it in the Email Migration dashboard. To delete a migration batch, select it and then click Delete . When you delete a migration batch, the migration service cleans up any records related to the migration batches and the batch is removed from the batch list.

Change the DNS Time-to-Live (TTL) setting on your MX record Before you start to migrate mailboxes, change the DNS TTL setting on your current MX record to a shorter interval, such as 3,600 seconds (one hour). Then, when you change your MX record to point to your cloud-based email organisation after all mailboxes are migrated, the updated MX record should propagate more quickly because of the shortened TTL interval.

Communicate with your users Give users a heads-up that you are migrating their on-premises mailbox to the cloud. Consider the following:

Ask users to delete old or unnecessary email messages from their Exchange mailbox before migration. This helps reduce the amount of data that has to be migrated and can help reduce the overall migration time. Or you can clean up their mailboxes yourself.

Suggest that users back up their Inbox.

When you receive the Migration Statistics report for a migration batch, tell users to start using their cloud-based mailboxes to send and receive email Give them the password to their new cloud-based mailbox (if applicable) and send them links to the following topics to help them connect to their cloud-based mailbox:

Require users to change their password In the CSV file, set the ForceChangePassword attribute to True. This forces users to change the password the first time they sign in to their new cloud-based mailbox and helps ensure that only the user knows the password. Be sure to encourage people to use strong passwords. However, as previously explained, if you’ve implemented a single sign-on solution by deploying AD FS 2.0 in your on-premises organisation, you must use False for the value of the ForceChangePassword attribute.

Tip If you use a unique password for each row in the CSV file, you can use the mail merge process in Microsoft Office Word and an edited version of your CSV file to provide users with the password for their new cloud-based accounts. See Send a Welcome Message to New Users.

Create an Autodiscover DNS record After all on-premises mailboxes are migrated to the cloud, you can configure an Autodiscover DNS record for your cloud-based organisation to enable users to connect to their new cloud-based mailbox with Microsoft Outlook and mobile clients. This new Autodiscover DNS record has to use the same namespace that you’re using for your cloud-based organisation. For example, if your cloud-based namespace is cloud.contoso.com, the Autodiscover DNS record you need to create is autodiscover.cloud.contoso.com.

Exchange Online uses a CNAME record to implement the Autodiscover service for Outlook and mobile clients. The Autodiscover CNAME record must contain the following information:

Configure your MX record to point to your cloud-based email organisation Until you change your MX record, email sent to users is still routed to their on-premises mailboxes and then forwarded to the corresponding cloud-based mailboxes. When you configure your organisation's MX record to point to your cloud-based email organisation, all email is sent directly to the cloud-based mailboxes.

Important It can take from 24 to 72 hours for the updated MX record to be propagated. Wait at least 24 hours after you change the MX record before you complete the migration. Verify that mail is being routed to cloud-based mailboxes.

Decommission on-premises Exchange servers When you’ve migrated all on-premises mailboxes to the cloud, converted all on-premises mailboxes to mail-enabled users and have verified that all email is being routed directly to the cloud mailboxes, you may no longer need to maintain all your on-premises Exchange servers for mail delivery. If this is the case, you can uninstall Exchange from your servers in your on-premises organisation. However, we strongly recommended that you maintain at least one Exchange server so that you have access to Exchange System Manager (Exchange 2003) or Exchange Management Console/Exchange Management Shell (Exchange 2007) to manage mail-related attributes on the on-premises mail-enabled users. For Exchange 2007, the Exchange server that you maintain should have the Hub Transport, Client Access, and Mailbox server roles installed. For more information, see the following: