Migrate Mailboxes to the Cloud with a Staged Exchange Migration

  • Article

Applies to: Office 365 for enterprises, Live@edu

You can use the E-mail 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 organization'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 organization.

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 organization, 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 e-mail organization. Depending on your organization type, you have to install and configure a directory synchronization tool before you can run a staged Exchange migration:
  • Microsoft Live@edu   Use Outlook Live Directory Sync (OLSync). For more information, see Implement Outlook Live Directory Sync for Live@edu.
  • Microsoft Office 365 for enterprises   Use the Microsoft Online Services Directory Synchronization tool. For more information, see Active Directory synchronization: Roadmap.
  • 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 synchronization.

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

In this topic

  • What happens during a staged Exchange migration
  • Before you begin
  • Step 1   Create a migration batch
  • Step 2   Configure the connection settings
    • Automatically detect connection settings with Autodiscover
    • Manually specify connection settings
  • Step 3   Upload the CSV file and name the migration batch
  • Step 4   Start a migration batch
  • Step 5   Convert on-premises mailboxes to mail-enabled users
  • Step 6   Create and start additional migration batches
  • Step 7   Delete a migration batch
  • Best practices
  • Next steps

Return to top

What happens during a staged Exchange migration

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 Synchronization tool is enabled for your cloud-based organization.
  • It checks that a mail-enabled user exists in the cloud-based e-mail organization 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 e-mail address of the cloud-based mailbox. This enables e-mail sent to an on-premises mailbox to be forwarded to the corresponding cloud-based mailbox.
  • It migrates e-mail 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 synchronized. New e-mail sent to the on-premises Exchange mailbox is forwarded to the corresponding cloud-based mailbox.
  • It sends an e-mail 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 e-mail migration carefully, especially verifying your ability to connect to your Exchange server. When you plan, check out Best practices.

  • Install and configure a directory synchronization tool for your cloud-based organization   OLSync or the Directory Synchronization tool must be running to perform a staged e-mail migration. The directory synchronization tool creates the mail-enabled users in your cloud-based organization that are converted to mailboxes during the migration. If OLSync isn’t installed in your Microsoft Live@edu organization, you can’t migrate mailboxes. If the Directory Synchronization tool isn't installed in your Office 365 for enterprises organization, 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 E-Mail Migration Overview.
    For more information about how to install a directory synchronization tool, see the following:

  • Plan for user identity management   After your on-premises mailboxes are migrated to the cloud, the synchronization 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 synchronization 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 organization 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.

    • Use the Microsoft Exchange Remote Connectivity Analyzer (ExRCA).

    • Run the following Windows PowerShell commands.

      $PSCredentials = Get-Credential

Test-MigrationServerAvailability -Autodiscover -EmailAddress <migration administrator e-mail address> -Credentials $PSCredentials

  • 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 a 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 e-mail 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 organization. For example, if the on-premises domain is named tailspintoys.com but the cloud-based e-mail organization is named service.tailspintoys.com you would use the tailspintoys.com domain name for e-mail 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 organization, 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.

    EmailAddress,Password,ForceChangePassword
pilarp@tailspintoys.com,P@ssw0rd,False
tobyn@tailspintoys.com,P@ssw0rd,False
iant@tailspintoys.com,P@ssw0rd,False

    For more information, see Prepare a CSV File for a Staged Exchange Migration.

  • Assign the migration administrator permissions to access mailboxes in your Exchange organization   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.

    Exchange 2007

    Exchange 2003

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

  • Verify that user mailboxes aren’t hidden in on-premises address lists   Migration will fail for on-premises mailboxes that are hidden from address lists. If a user’s mailbox is hidden, clear the Hide from Exchange Address lists checkbox on the user’s properties page in the Exchange Management Console.

  • **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.

Return to top

Step 1   Create a migration batch

  1. Select Manage My Organization > Users & Groups > E-Mail Migration > New. On the Welcome to E-mail Migration page, select one of the following migration types:
    • 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.
  2. 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

  1. 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 E-Mail Migration to create a new migration batch.

    In this field… Do this…

    * Migration administrator e-mail address

    Type the e-mail 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 optimize this setting, see Maximum Number of Connections to Your Mail Server.

  2. Click Next. Microsoft Exchange tries to communicate with the on-premises Exchange server to verify the Autodiscover connection settings.
    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

  1. 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 e-mail 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 optimize this setting, see Maximum Number of Connections to Your Mail Server.

  2. 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 Synchronization tool is enabled for your organization, and then displays the Specify what and how to migrate (Step 2 of 3) page.
    Note   If the Directory Synchronization tool isn't enabled for your organization, 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 Synchronization tool and then restart E-mail Migration.

Step 3   Upload the CSV file and name the migration batch

  1. Click Browse to select the CSV file for the migration batch.
  2. In the Batch name field, type a name that identifies the migration batch. This name is displayed in the E-Mail Migration dashboard. Batch names can’t contain spaces or special characters.
  3. To send copies of the migration reports to other users, click Browse at the bottom of the page.
  4. Click Next.
    Important   When you click Next, you are agreeing to give the migration service permission to set the TargetAddress property on the on-premises mailboxes to enable e-mail forwarding. For more information, see Give the Migration Service Permission to Configure Mail Forwarding for Cloud-based Mailboxes.
  5. Microsoft Exchange checks the CSV file for the following:
    • It isn't empty.
    • It uses comma-separated formatting.
    • It doesn't contain more than 1,000 rows.
    • It includes the required EmailAddress column in the header row.
    • It contains rows with the same number of columns as the header row.
      If any one of these checks fails, you'll get an error that describes the reason for the failure. At this point, you have to fix the CSV file and resubmit it. For more information, see Prepare a CSV File for a Staged Exchange Migration.
      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.
  6. 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 E-mail 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 E-mail 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 move up or move down.
  • 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 move up or move down.
  • 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 organization. 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.

Errors

The number of mailboxes that failed migration.

Creation Time

Date and time when the migration batch was created.

Start Time

Date and time when the migration batch was started.

Initial Sync Time

Date and time when the migration batch was completed.

Initial Sync Duration

The amount of time it took to complete the migration batch.

Last Sync Time

The last time the migration batch was re-started.

Per-User Details

Click Open to display status information about each mailbox in the migration batch. For more information, see E-Mail Migration Users Status Report.

Reports

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 e-mail 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 e-mail address of the mailbox and a description of the error.

Monitor a migration batch

Use the E-mail 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:

Stop a migration batch

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 after the previous migration batch is 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.

After you stop a migration batch that was running, you receive a status e-mail 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 that 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 synchronization 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 e-mail. 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 organization by using Active Directory. Also, if you decide to decommission your on-premises Exchange organization 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:

Step 6   Create and start additional migration batches

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

Return to top

Step 7   Delete a migration batch

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 E-mail Migration dashboard. To delete a migration batch, select it and then click Delete 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.

Return to top

Best practices

Here are some tips to optimize your Exchange migration:

  • 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 e-mail organization 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 e-mail 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 e-mail   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 organization, 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.

Return to top

Next steps

  • Assign licenses to Office 365 users   If you have a Microsoft Office 365 e-mail organization, you must assign licenses to new mailboxes or they will be disabled when the grace period ends. For more information, see Assign a License to New Mailboxes in Office 365.

  • 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 organization 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 organization. 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 e-mail organization   **Until you change your MX record, e-mail sent to users is still routed to their on-premises mailboxes and then forwarded to the corresponding cloud-based mailboxes. When you configure your organization's MX record to point to your cloud-based e-mail organization, all e-mail 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   After you’ve migrated all on-premises mailboxes to the cloud, converted all on-premises mailboxes to mail-enabled users, and have verified that all e-mail 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 organization. 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:

    Warning

    Decommissioning Exchange can have unintended consequences. Before decommissioning your on-premises Exchange organization, we recommend that you contact Microsoft Support.