Migration/Deployment Office 365



ms offfice 365
Start your Trial with 5thNK and we 
can guide you through process and procedure. 
You pay ZERO extra yet have an IT Person on hand. 
You know what this web site stands for?
(I)nformation (T)echnology takes a Team. www.ITTakesaTeam.net 

 5thNK  We at 5thNK do this every day! 
"We are the BEST Microsoft Office 365 Partner in the World"

There are several methods to migrate 

all mailboxes to Office 365 for enterprises

Office 365 Migration Pricing

 

CLIENT SERVICES AGREEMENT –

 

Option One: Location On-Premise (this means we drive to your office and work onsite) Means you are not in Zimbabway, rather in the Seattle Area. 

 

Summary: Decommission server and move all e-mail and files to Microsoft’s Office 365 system – E-mail would reside in Exchange Online, and files would be stored in SharePoint Online.

 

Includes:

·        24/7 monitoring of all PCs with Intune

·        Cloud-based backup software (what do you sell?)

·        Managed anti-virus on each PC (with Intune)

·        SonicWall firewall (cost separately based on # of users)

 

Benefits:

·        No server on-site to support/maintain

·        Most software is fully cloud-based, so it can be accessed from anywhere

·        No capital costs to purchase/upgrade server

 

Drawbacks:

·        All files hosted on a remote system, so access speed is reduced by the Internet

 

Costs:

·        Labor $600 per user

·        Migrate e-mail and files to new system

·        Install new & clean-up and reconfigure older PCs to Windows 7

·        Upgrade Office to 2010 version using Office 365 subscription

 

 

Monthly Costs

·        InTune Computing Cloud Services $15 per PC/mo

·        Includes Managed AV, Monitoring

·        Office 365 with Office 2010 Professional Plus Subscription $20/mo/user

 

 


Applies to: Office 365 for enterprises


If your long-term goal is to move all mailboxes to the cloud, you must evaluate your current on-premises e-mail infrastructure and select the migration tool and method that works best for your organization. There are several methods to migrate all mailboxes to Office 365 for enterprises. Each method has advantages and disadvantages for administrators and users, and each method has specific requirements and dependencies.

If you are currently managing an on-premises e-mail system and now are deploying Microsoft Office 365 for enterprises, you need to plan carefully. First, consider your long-term goals:    

  • If your long-term goal is to maintain mailboxes both in your on-premises organization and in the cloud, you should deploy Exchange in your on-premises organization in what is called a hybrid deployment.
    A hybrid deployment requires Microsoft Exchange Server 2010. However, a full Exchange 2010 organization isn’t required to enable a hybrid deployment. You can install a minimal Exchange 2010 hybrid server in an existing Exchange 2003 or Exchange 2007 organization.
  • If your long-term goal is to move all mailboxes to the cloud, you must evaluate your current on-premises e-mail infrastructure and select the migration tool and method that works best for your organization. There are several methods to migrate all mailboxes to Office 365 for enterprises. Each method has advantages and disadvantages for administrators and users, and each method has specific requirements and dependencies.

This topic is designed to help you understand all the options and plan your deployment. It explains the terminology and describes the deployment options and the tools that are included with Exchange Online and Office 365 for enterprises as follows:

Terminology: The secret decoder ring

As you explore the software and supporting documentation, you’ll see that we’ve used terms like “rich coexistence” and “simple coexistence”, and “cross-premises deployments” and “hybrid deployments.” These terms represent the evolution of the software to handle the basic “cross-premises” scenario.

We’re working to nail down the terminology. In the meantime, we hope this table helps you make sense of the terminology being used in the software and documentation.

Term

Description

hybrid deployment

The full-featured deployment of a cross-premises Exchange messaging solution with Office 365 for enterprises and Exchange Online. Features include:

  • Mail routing between on-premises and cloud-based organizations
  • Mail routing with a shared domain namespace. For example, both on-premises and cloud-based organizations use the @contoso.com SMTP domain.
  • A unified global address list, also called a “shared address book”
  • Free/busy and calendar sharing between on-premises and cloud-based organizations
  • Centralized control of mail flow. The on-premises organization can control mail flow for the on-premises and cloud-based organizations.
  • A single Outlook Web App URL for both the on-premises and cloud-based organizations
  • The ability to move existing on-premises mailboxes to the cloud-based organization
  • Centralized mailbox management using the on-premises Exchange Management Console (EMC)
  • Message tracking, MailTips, and multi-mailbox search between on-premises and cloud-based organizations

hybrid

A shortened form of “hybrid deployment”

cross-premises

A generic phrase that refers to any messaging deployment where mail routing spans an on-premises deployment and a cloud-based organization.

rich coexistence

See “hybrid deployment”. The term “rich coexistence” has been replaced by “hybrid deployment”.

simple coexistence

An obsolete term referring to cross-premises deployments where Exchange 2010 isn’t deployed in the on-premises environment. In our development, we’ve found that this term is overly broad and so we’ve decided not to carry it forward. You will see “simple coexistence” referenced in some documentation and user interface.

Exchange migration

The Exchange Online functionality that you can use to move mailboxes, or in the case of IMAP e-mail migration, the contents of users' mailboxes, from your on-premises Exchange organization to the cloud. You’ll find the Exchange Online migration tools on the E-Mail Migration tab in the Exchange Control Panel. There are three types of Exchange migration:

  • Cutover Exchange migration, referred to previously as simple Exchange migration.
  • Staged Exchange migration, which allows you to maintain mail routing across an on-premises deployment and a cloud-based organization for the short or long term
  • IMAP e-mail migration, used to migrate the contents of users' mailboxes from an IMAP messaging system to their cloud-based mailbox

single sign-on

The authentication process that lets your users use their existing Active Directory corporate credentials (user name and password) to access services in Office 365 for enterprises. Also called identity federation, single sign-on in Microsoft Office 365 uses Active Directory Federation Services 2.0 (AD FS).

identity federation

Also used to describe “single sign-on”, this term is used in Microsoft Office 365 documentation but will be phased out in favor of “single sign-on”. See the wiki post Federation in Office 365 and Exchange for an explanation of federation terminology used in Office 365.

hybrid server

A computer that is running a Hybrid edition of Exchange Server 2010 and is installed in an Exchange Server 2007 or Exchange Server 2003 organization for the purpose of enabling a hybrid deployment. This was previously referred to as a “coexistence server” in some documentation.

Return to top

Primary long-term e-mail deployment options

The Office 365 for enterprises planning and deployment tools have been designed to support either of the following long-term e-mail deployment options:

  • Hybrid deployment Mailboxes for your organization can reside on-premises in an Exchange organization and in the cloud. In the hybrid deployment scenario, messaging functionality is seamless across the on-premises deployment and the cloud deployment. For the full list of supported features, see “Hybrid deployment” in the preceding table.
    This hybrid deployment scenario can also include single sign-on, which lets users use their existing Active Directory on-premises credentials to access all on-premises and cloud resources.
  • All mailboxes in the cloud If your long-term goal doesn’t require messaging functionality that spans cross-premises, you should plan to move all your mailboxes to the cloud. It may take a week or maybe months to complete the migration, but it’s the best option if your long-term goal is to migrate all your mailboxes to the cloud.

As we explain in the next section, many of the migration and cross-premises tools that have been developed to support these two long-term mailbox options can be used to support other cross-premises scenarios. However, the planning and deployment tools built in to Office 365 for enterprises and Exchange Online have been designed to support moving all mailboxes to the cloud and to support a hybrid deployment.

Return to top

Additional deployment options

Using the tools described in this document, you can put together other solutions that may work for your organization, for the short term, during migration only, or for the long term. Let’s take a quick look at these options.

Manage on-premises users with Office 365 tools

An alternative form of migration is to move all mailboxes to the cloud, but to continue to manage users and resources from your existing Active Directory. After you set up single sign-on and install the Microsoft Online Services Directory Synchronization tool, users can use their Active Directory corporate credentials (user name and password) to access their new mailboxes in the cloud and their existing on-premises resources. If your organization is running Exchange 2003 or a later version, and you have fewer than 1,000 mailboxes, you can run cutover Exchange migration to move your mailboxes and then configure single-sign on. For more information, see Cutover Exchange Migration and Single-Sign On.

Or, if you’re currently running Exchange 2003 or Exchange 2007 on-premises, you can use staged Exchange migration to enable this scenario. For more information, see Plan for User Identity in a Staged Exchange Migration.

Provision users from your on-premises Active Directory into the cloud

If you don’t require single sign-on, deploying Active Directory synchronization only in the on-premises organization lets you provision users from your on-premises Active Directory into the cloud. This solution may work for organizations that maintain mail routing between a cloud-based organization and a non-Exchange on-premises messaging system, or organizations that simply prefer to source all users from their on-premises Active Directory. Organizations with many users should consider a custom solution to synchronize passwords from the on-premises organization to the cloud for this scenario.

Explore third-party solutions

If you aren’t running Exchange 2003 or later, or you are running a web-based messaging system or some other on-premises messaging system, you may need to work with a partner to figure out a solution that meets your needs using the tools discussed in this paper. For example, IMAP e-mail migration may suffice as a method to move mailbox data for your users, while a third-party solution may be the answer to migrating messaging-based workflow solutions to Exchange Online.

Return to top

The variables: Things to consider as you prepare to deploy

After you’ve decided on your long-term e-mail deployment option, you need to learn about the tools that you can use to move mailboxes to the cloud and to make the migration phase a better experience for your users and IT staff. You should also take routing, mail flow, and identity management into account when you plan for migration or a hybrid deployment.

  • Identity management
  • Microsoft Online Services Directory Synchronization tool
  • Mail routing
  • Migration methods and tools

Identity management

How do you want to manage the identities of the users in the cloud? You have two options:

  • Non-federated identity
  • Single sign-on (also known as identity federation)

Non-federated identity

With non-federated identity, all users with mailboxes in the cloud use Office 365-generated credentials to access their Office 365 resources. You can create new user accounts and passwords for Office 365 users in the Office 365 portal. Alternatively, you can use directory synchronization to automatically provision users from the on-premises Active Directory. Either way, ultimately, credentials are generated and managed by Office 365.

If you have an on-premises identity management system, users will have a set of credentials for their Office 365 resources and a set of credentials for their on-premises resources.

The advantage of a non-federated identity management solution is that there is less overhead in deploying and setting up your identity solution. For some small organizations or for organizations that are moving all user resources to the cloud in the near future, a non-federated identity management solution is ideal.

The disadvantage to a non-federated identity solution for organizations that still maintain user resources on-premises is that the user experience is fractured and requires more user education about credential management. Support may be costly if you expect users to manage two sets of credentials for accessing many different resources across two deployments.

For medium-sized or large organizations, long-term management and helpdesk costs will likely make a non-federated identity solution more expensive than single sign-on.

Single sign-on

When you deploy single sign-on, all users with mailboxes in the cloud use their existing on-premises Active Directory credentials to access both cloud and on-premises resources.

In a nutshell, you enable this by installing an AD FS server or servers in your on-premises organization. The AD FS server federates to the Office 365 service in the cloud to provide delegated access for your on-premises identities to specific Office 365 and Exchange Online resources in your cloud-based domain namespace.

The advantage of single sign-on is that users don’t need to learn a new credential management scheme. In addition to the user benefits, there are many benefits to administrators:

  • Policy control: The administrator can control account policies through Active Directory, which gives the administrator the ability to manage password policies, workstation restrictions, lock-out controls, and more, without having to perform additional tasks in the cloud.
  • Access control: The administrator can restrict access to Office 365 so that the services can be accessed through the corporate environment, through online servers, or both.
  • Reduced support calls: Forgotten passwords are a common source of support calls in all companies. If users have fewer passwords to remember, they are less likely to forget them.
  • Security: User identities and information are protected because all of the servers and services used in single sign-on are mastered and controlled on-premises.
  • Support for strong authentication: You can use strong authentication, also called two-factor authentication, with Office 365. However, if you use strong authentication, you must use single sign-on.

After you deploy AD FS and directory synchronization, you manage all users and resources from your existing on-premises Active Directory.

The disadvantage of single sign-on is that you have to install new servers, which require a certificate issued by a certification authority (CA) and add some complexity and cost to user management.

Note Single sign-on is recommended, though not required, in the hybrid deployment scenario.

Single sign-on may also be a good solution for some large organizations that plan to migrate all mailboxes to Office 365 over many months.

Over time, for most organizations that plan to maintain an on-premises set of Active Directory resources along with Office 365, single sign-on is a good solution for streamlining user identity management.

Important

  • Single sign-on with AD FS requires Active Directory on-premises.
  • Single sign-on requires that you install and run the Microsoft Online Services Directory Synchronization tool.
  • If you plan to migrate all mailboxes to the cloud and set up single sign-on, you can’t deploy AD FS or directory synchronization before you run a cutover Exchange migration in the Exchange Control Panel. You can, however, run a staged Exchange migration after you deploy AD FS and directory synchronization.

For more information, see Prepare for single sign-on, and Plan for and deploy Active Directory Federation Services 2.0 for use with single sign-on.

Return to top

The Microsoft Online Services Directory Synchronization tool

The Microsoft Online Services Directory Synchronization tool is primarily used to synchronize the Exchange global address list, also known as the shared address book, support complex routing scenarios, and provision users in a cross-premises deployment. Directory synchronization is a requirement for the hybrid deployment scenario, and it may produce a better user experience in some migration scenarios, especially if you plan to enable single sign-on.

However, from a user management perspective, directory synchronization is intended for long-term use. Although you can deactivate (and reactivate) directory synchronization, you should consider the deployment of directory synchronization as a long-term commitment. For more planning information about deactivating and reactivating directory synchronization, see the wiki post, Directory synchronization and source of authority.

By default, the Directory Synchronization tool synchronizes one-way from the on-premises directory to the cloud directory by writing user and mailbox information into the cloud directory for your Office 365 organization.

To enable some features of hybrid deployment, you must grant write access to the Directory Synchronization tool to synchronize some messaging-related user data back into the on-premises Active Directory. The following features are enabled by write access synchronization with your on-premises Active Directory:

  • Archiving on-premises mailboxes to the cloud
  • Moving mailboxes from the cloud to the on-premises Exchange organization
  • Synchronizing user-managed safe sender and blocked sender lists from the cloud
  • Synchronizing voice mail notifications from the cloud

Important Directory synchronization is required for the following: hybrid deployment; single sign-on; and staged Exchange migration.

For more information, see Active Directory synchronization: Roadmap.

Return to top

Mail routing

Generally speaking, mail routing for a hybrid deployment is straightforward. The tools (mainly the Directory Synchronization tool) are optimized for pointing your MX record to your on-premises Exchange system as the authoritative domain. E-mail to cloud-based recipients is then relayed from the on-premises Exchange organization to the cloud. The Exchange Server Deployment Assistant explains how to configure this routing scheme for hybrid deployments.

You can also configure routing for hybrid deployments so that the MX record points to the cloud as the authoritative domain. For more information, see Hybrid Routing – Pointing your MX record to the Cloud.

More complex mail routing configurations typically come into play only if you are planning a long-term deployment where messaging systems span the on-premises and cloud deployments. In most cases, if you plan to migrate all your mailboxes to the cloud, you don’t need to consider complex mail routing scenarios. The exception here may occur for long, staged migrations where advanced mail routing might be required to maintain e-mail quality of service during the migration.

Important Both cutover Exchange migration and staged Exchange migration manage short-term e-mail synchronization during the migration phase. Cutover Exchange migration synchronizes e-mail using subscriptions until migration is complete. Staged Exchange migration routes e-mail by stamping the cloud target address on the on-premises mailboxes.

Return to top

Migration methods and tools

The following migration methods and tools are available:

  • Move requests with the Mailbox Replication Service (MRS)
  • Cutover Exchange migration
  • Staged Exchange migration
  • IMAP e-mail migration
  • Third-party solutions

The Exchange Server Deployment Assistant explains how deploy most of these solutions.

Move requests with the Mailbox Replication Service (MRS)

The Microsoft Exchange Mailbox Replication Service (MRS), which resides on all Exchange 2010 Client Access servers, is the service responsible for mailbox moves, importing and exporting .pst files, and restoring disabled and soft-deleted mailboxes.

Move requests require a hybrid deployment. Move requests let you move mailboxes back and forth between your on-premises Exchange organization and the cloud. You do this in the Exchange Management Console.

If you plan to migrate and implement a long-term hybrid deployment with Exchange on-premises, move requests are the recommended way to migrate mailboxes.

Also, for large organizations that are running Exchange 2003 or Exchange 2007 on-premises and plan to move all mailboxes to the cloud over a period of several months, using move requests as a tool for a long, staged Exchange migration, which is essentially a hybrid deployment, may make sense.

Important Move requests require a minimal installation of an Exchange 2010 hybrid server in your on-premises Exchange organization. You must be running Exchange 2003 or later to deploy the hybrid solution. The Exchange Server Deployment Assistant can help you generate a hybrid deployment plan.

For more information, see the following:

Cutover Exchange migration

Cutover Exchange migration is for organizations that have fewer than 1,000 mailboxes and want to move all mailboxes to the cloud in a single operation. Use E-Mail Migration in the Exchange Control Panel to access the tool.

Important

  • Cutover Exchange migration only supports Exchange 2003 or later. If you are running older versions of Exchange, you have to use IMAP e-mail migration or a third-party solution.
  • If you are running Exchange and have more than 1,000 mailboxes, consider using staged Exchange migration.
  • If you plan to deploy single sign-on, run cutover Exchange migration first, and then set up single sign-on (and directory synchronization after the migration is complete). Running directory synchronization before you run cutover Exchange migration will cause the migration to fail.

For more information, see the following Exchange Online topics:

Staged Exchange migration

Staged Exchange migration is for larger organizations or organizations that want to migrate mailboxes to the cloud over time. In this scenario, you can migrate some mailboxes to the cloud while maintaining the rest of the mailboxes in your on-premises organization. Use E-Mail Migration in the Exchange Control Panel to access the tool.

Important

  • Staged Exchange migration has been designed for organizations that plan to move all on-premises Exchange mailboxes to the cloud eventually. It’s not a best practice to use staged Exchange migration to migrate a handful of mailboxes as part of a longer coexistence scenario.
  • Staged Exchange migration only supports Exchange 2003 or Exchange 2007. If you are running older versions of Exchange, you have to use IMAP e-mail migration or a third-party solution. If you are running Exchange 2010, you must implement a hybrid deployment and use move requests to migrate.
  • Staged Exchange migration requires directory synchronization.
  • If you plan to deploy single sign-on as part of your long-term deployment plan, set up single sign-on and directory synchronization before you run the staged Exchange migration.

For more information, see the following:

IMAP e-mail migration

IMAP e-mail migration is designed as a fallback e-mail content migration tool for a wide variety of e-mail servers. If you are running Exchange 2000 Server or Exchange Server 5.5 Service Pack 4, or any other compliant IMAP server, such as Gmail, IMAP e-mail migration is an option. Use E-mail Migration in the Exchange Control Panel and a CSV file.

For more information, see the following Exchange Online topics:

Third-party solutions

Here are some third-party migration tools and partners that can assist with Exchange migrations from non-Microsoft platforms:

  • Binary Tree Provider of cross-platform messaging migration and coexistence software with products that provide for the analysis of, and the coexistence and migration between, on-premise and online enterprise messaging and collaboration environments based on IBM Lotus Notes and Domino, and Microsoft Exchange and Microsoft SharePoint.
  • BitTitan Provider of self-service e-mail migration and coexistence solutions to Exchange 2007 and Exchange Online.
  • Cemaphore Provider of migration solutions from on-premises Microsoft Exchange to Microsoft Online.
  • Quest Provider of migration solutions for Exchange Online and SharePoint Online, including migrations from Lotus Notes and Novell GroupWise to Exchange Online.
  • Metalogix Provider of migration solutions to Exchange Online and SharePoint Online.

Return to top

©2012 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks | Privacy Statement
DCSIMG
                                                                       
                                                                                                               Office 365 
Call us 206 452 3331 Microsoft Partner since 2009
5thNK  We at 5thNK do this every day! 

Migrate E-Mail from an IMAP Server to Cloud-based Mailboxes

Applies to: Office 365 for professionals and small businesses, Office 365 for enterprises, Live@edu

Topic Last Modified: 2011-12-02

Use E-mail Migration in the Exchange Control Panel to migrate the contents of user mailboxes from an IMAP messaging system to your cloud-based e-mail organization.

To start an IMAP migration, select Manage My Organization > Users & Groups > E-Mail Migration > New. On the Welcome to E-mail Migration page, select IMAP and click Next.

Important   For an IMAP migration, you can only migrate a user’s inbox or other mail folders. You can’t migrate contacts or calendar items. Additionally, a maximum of 500,000 items can be migrated from a user’s mailbox.

Before you begin

Before you migrate mail from an IMAP server, be sure to plan your e-mail migration carefully, especially if you're migrating lots of users. When you plan, make sure to check out Best practices.

To prepare for the migration:

  • Create a cloud-based mailbox for each user that you will migrate   Before you can migrate data from a user's mailbox on the IMAP server, the user has to have a cloud-based mailbox and user ID. Here's how to create new mailboxes and user ID for each user:
  • Obtain the FQDN for your IMAP server   You need to provide the FQDN of the IMAP server that you will migrate mailbox data from, for example, imap.contoso.edu.
    Tip   Use an IMAP client or the PING command to verify that you can use the FQDN to communicate with the IMAP server over the Internet.
  • Configure your on-premises firewall to allow IMAP connections   You may have to open ports in your on-premises firewall so network traffic originating from the Microsoft datacenter during the migration is allowed to enter your on-premises organization. For a list of IP addresses used by Microsoft datacenters, seeExchange Online URLs and IP Address Ranges.
  • Decide which folders you don't want to migrate from the IMAP messaging system   For example, you may not want to migrate the contents of the Deleted Items and Junk Mail, and shared or public folders.
    Important   If you're migrating e-mail from an on-premises Microsoft Exchange server, we recommend that you exclude public folders from the migration. If you don't exclude public folders, the contents of the public folders are copied to the cloud-based mailbox of every user.
  • Prepare the CSV file   Identify the group of users whose mailboxes you want to migrate. Include these users in the CSV file that will make up the migration batch. If you have to migrate thousands of mailboxes, it's a good idea is to migrate users in several smaller batches. For example, if you have 10,000 accounts to migrate, you could run four batches with 2,500 users each, or you could divide the batches alphabetically, by user type, such as faculty, students, and alumni, by class, such as freshman, sophomore, junior, and senior, or in other ways that will help you keep track of the users you've migrated.
    Here are the required attributes for each user: 
    • EmailAddress specifies the user ID for the user's cloud-based mailbox.
    • UserName specifies the user logon name for the user's mailbox on the IMAP server.
    • Password is the password for the user's account in the IMAP messaging system. 
    Here's an example of the format for the CSV file. In this example, three mailboxes are migrated:
    EmailAddress,UserName,Password
    terrya@contoso.edu,terry.adams,1091990
    annb@contoso.edu,ann.beebe,2111991
    chrisc@contoso.edu,chris.cannon,3281986
    
    For the UserName attribute, in addition to the user name, you can use the credentials of a super-user account or administrator account that has the rights to access all mailboxes on the IMAP server. For more information, see Prepare a CSV File to Migrate E-mail from an IMAP Server.
    Tip   Use the CSV file that you used to import new users as the starting point for CSV migration file. For example, if you import 2,000 new users to your organization in the cloud, create a CSV file to migrate mail for those same 2,000 users.
  • Assign the super-user or administrator account permissions to access mailboxes in your Exchange organization   If you use administrator credentials in the CSV file, the account that you use must have the necessary permissions to access the on-premises 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 2010

    Allow Mailbox Access

    Exchange 2007

    Exchange 2003

Return to top

Run a migration batch

Step 1: Configure your server settings for e-mail migrations

  1. Select Manage My Organization > Users & Groups > E-Mail Migration > New.
  2. On the Welcome to E-mail Migration page, select IMAP and click Next.
  3. Configure the server settings.
    In this field…Do this…

    * IMAP server

    Type the FQDN of the IMAP server for the IMAP messaging system.

    Authentication

    Select the authentication method used by the IMAP server. Options areBasic, the default, or NTLM. Use NTLM if it's required by your IMAP server.

    Encryption

    Select the encryption method used by the IMAP server. Options are None,TLS, or SSL, the default.

    * Port

    Select the TCP port number used to connect to the IMAP server. Use port 143 for unencrypted connections, port 143 for TLS connections, and port 993 for SSL connections.

    Number of mailboxes to migrate simultaneously

    Specify the number of connections to the IMAP 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 10. To learn more about how to optimize this setting, seeMaximum Number of Connections to Your Mail Server.

    Note   The server settings you configure will persist on this page the next time you run E-Mail Migration to migrate a new batch of mailboxes.
  4. Click Next. Microsoft Exchange tries to communicate with the IMAP server to verify the server's FQDN and the port used to receive the IMAP requests. If the test connection to the IMAP server is successful, the Exclude specific folders from e-mail migration page is displayed. If the test connection isn't successful, you'll get an error. Verify the configuration settings and try to connect again. You have to connect to the IMAP server to continue.

If you can’t connect to the IMAP server, see this video for troubleshooting tips.

Return to top

Step 2: Exclude specific folders from e-mail migration

You may not want to migrate the contents of certain folders in users' mailboxes, such as Deleted Items or Junk E-Mail. You can also exclude shared and public folders. Here's how:

  1. Click Add folders to exclude. Type the name of the folder and click Add Add. Be sure to type the folder name exactly as it appears, for example, Deleted Items.
  2. You can add more than one folder to the list. When you are finished adding folders, click OK.
  3. Click Next.

Important   If you're migrating e-mail from an on-premises Microsoft Exchange server, we recommend that you exclude public folders from the migration. If you don't exclude public folders, the contents of the public folders are copied to the cloud-based mailbox of every user.

Also, folders with a forward slash ( / ) in the name aren't migrated. If users want to migrate folders that contain forward slashes in their names, they have to rename the folders or replace the forward slash with a different character, such as an underscore character ( _ ) or a dash ( - ).

Step 3: Upload a batch of mailboxes to migrate

  1. Click Browse to select the CSV file for the migration batch.
  2. After you select the CSV file, click Next. Microsoft Exchange checks the CSV file for the following:
    • It isn't empty.
    • It uses comma-separated formatting.
    • It doesn't contain more than 50,000 rows.
    • It isn't larger than 10 MB.
    • It includes the required attributes in the header row:
      • EmailAddress, which specifies the Windows Live ID for the user's cloud-based account
      • UserName, which specifies the user logon name for the user's mailbox in the IMAP messaging system
      • Password, which specifies the password for the user's account in the IMAP messaging system
    • 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 to Migrate E-mail from an IMAP Server.
    If the CSV file successfully passes these checks, you'll move on to the Start the migration page.

Return to top

Step 4: Start the migration

In addition to the checks described in step 3, Microsoft Exchange also checks for data validation errors in the CSV file. If data in any row of the CSV file doesn't meet the property definition for the corresponding attribute in the header, you'll get an error. The migration process isn't terminated if data validation errors are found, but e-mail won't be migrated for the mailboxes that correspond to the rows that have data validation errors. If data validation errors are found, a warning and a link to the validation error report are displayed on the Start the migration page. For more information, see Troubleshoot Migration Validation Errors.

To start the migration:

  1. Decide if you want Microsoft Exchange to send a status e-mail message to other users when the migration batch is done running. If so, click the Browse to select one or more users.
  2. Review the migration settings. 
    • To start processing the migration batch, click Run.
    • To cancel the current migration batch and return to step 1, click Start Over.

Return to top

What happens after you start the migration batch?

After you start the migration, two panes are displayed on the E-Mail Migration tab:

  • Active E-Mail Migration   This pane contains the following information about the migration batch in progress:
    • The name of the CSV file used for the migration batch
    • The date and time when the migration batch was started, and the user who started the migration
    • The total number of migrations requested. This number corresponds to the number of rows in the CSV migration file.
    • The number of migration requests from the current migration batch that have been completed. This field is updated throughout the migration.
    • The number of active mailbox migrations. This number corresponds to the number of simultaneous connections that you specified in step 1 of setting up the migration.
    • A link to the Active Mailbox Migration Report, which shows detailed information about each mailbox that is being actively migrated. A compilation of this report, which contains similar information for all the mailboxes in the migration batch, is included in the status e-mail sent to the administrator after the migration batch is finished.
    • The number of mailboxes that failed to be migrated 
    • A link to the Error Report for Active Migrations that documents each migration error found during the processing of the current migration batch. For each error, the report includes a suggestion for fixing the error. Use this information to fix the error, and then submit a revised CSV file for a new migration batch. For more information, see Troubleshoot Active Migration Errors.
    Click Refresh Refresh periodically to refresh this pane during the processing of the current migration batch. When the migration batch is done, the Active E-Mail Migration pane is no longer displayed.
  • E-Mail Migration   This pane contains information about the overall migration, which consists of all the migration batches that you've run. It contains the following information:
    • The number of mailboxes from all migration batches that have been migrated and are actively being synchronized with the corresponding on-premises mailbox
    • The number of synchronization errors that have occurred since the migration was started
    • A link to the Error Report for Synchronization Failures, which identifies synchronization failures that are preventing Microsoft Exchange from retrieving new e-mail messages sent to a user's mailbox in the IMAP messaging system. For more information, see Troubleshoot Migration Synchronization Failures.

Return to top

Stop a migration batch

To stop a migration batch, in the Active E-Mail Migration pane, click Stop.

You can only stop migration batches that have mailboxes in the process of being migrated or are waiting to be migrated. The migration of any mailbox currently being processed is stopped immediately and is not completed. Also, stopping a migration batch won't affect mailboxes that have been migrated already.

After you stop a migration batch, you receive a status e-mail message that says how many mailboxes were successfully migrated before the batch was stopped. This message also has an attached MigrationErrors.csv file that identifies the rows that were in progress when the migration was stopped and the rows waiting to be migrated.

Start additional migration batches

After the current migration batch is complete, repeat steps 1 through 4 to run additional migration batches. Each migration batch uses its own CSV file.

Return to top

Complete the migration

After you've run all your IMAP migration batches for the mailboxes you plan to migrate, you're ready to complete the migration. Follow these steps:

  1. 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 mailboxes in the IMAP messaging system. When a user mailbox is successfully migrated, the mailbox on the IMAP server and cloud-based mailbox are periodically synchronized until you complete the overall migration. This lets users use their cloud-based account to access e-mail sent to their IMAP mailbox. 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.
    After you change the MX record and verify that all e-mail is being routed to cloud-based mailboxes, you're ready to complete the migration.
    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 before you complete the migration.
  2. Complete the overall migration process   Click Complete Migration in the E-Mail Migration pane. What happens when you click Complete Migration?
    • Microsoft Exchange runs a final synchronization for all mailboxes. After this, e-mail is no longer synchronized between mailboxes on the IMAP messaging system and cloud-based mailboxes.
    • Microsoft Exchange sends a final status e-mail message after the migration is complete. If there are any errors during the final synchronization process, a MigrationErrors.csv file that lists the errors is attached to this message.

Return to top

Best practices

Here are some tips to optimize your IMAP migration:

  • Increase the connection limits to your IMAP server   Many firewalls and e-mail servers have per-user limits, per-IP address limits, and overall connection limits. Before you migrate mailboxes, make sure that your firewall and IMAP server are configured to allow a large, or maximum, number of connections for the following settings:
    • The total number of connections to the IMAP server
    • The number of connections by a particular user. This is important if you use administrator credentials in the CSV migration file because all connections to the IMAP server are made by this user account.
    • The number of connections from a single IP address. This limit is typically enforced by the firewall or the e-mail server.
    If your IMAP server is running Microsoft Exchange Server 2010 or Exchange 2007, the default settings for connection limits are low. Be sure to increase these limits before you migrate e-mail. By default, Exchange 2003 doesn't limit the number of connections.
    For more information, see:
  • Change the DNS Time-to-Live (TTL) setting on your MX record   Before you start migrating mailboxes, change the DNS TTL setting on your current MX record to a shorter interval, such as 3600 seconds (one hour). Then, when you change 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.
  • Run one or more test migration batches   Run a few small IMAP migration batches before you migrate larger numbers of users. In a test migration, you can do the following:
    • Verify the format of the CSV file.
    • Test the settings used to connect to the IMAP server
    • Verify you can successfully migrate e-mail using super-user credentials, if applicable.
    • Determine the optimal number of simultaneous connections to the IMAP server that minimize the impact on your Internet bandwidth. For more information, seeMaximum Number of Connections to Your Mail Server.
    • Verify that folders you exclude aren't migrated to the cloud-based mailboxes.
    • Determine how long it takes to migrate a batch of users.
    Use CSV files with the same number of rows and run the batches at similar times during the day. Then compare the total running time for each test batch. This will help you estimate how long it will take to migrate all your mailboxes, how large each migration batch should be, and how many simultaneous connections to the IMAP server you should use to balance migration speed and Internet bandwidth.
  • Create mailboxes and migrate e-mail for the same batch of users   Use the CSV file that you used to import new users as the starting point for the CSV file. For example, if you import 2,000 new users to your cloud-based e-mail organization, create a CSV file to migrate mail for those same 2,000 users. This is an effective way to organize and manage your migration from an on-premises messaging system to your cloud-based organization.
  • Use super-user or administrator credentials in the CSV file to migrate e-mail   This method is the least disruptive and inconvenient for users, and it will help minimize synchronization errors caused when users change the password on their on-premises account. It also saves you from having to obtain or change user passwords. If you use this method, be sure to verify that the administrator account you use has the necessary permissions to access the mailboxes you are migrating.
    Tip   If you decide to use user credentials in the CSV file, consider globally changing users' passwords and then preventing users from changing their password on their on-premises account before you migrate their mailboxes. If users change their password before their mailbox is migrated to the cloud-based mailbox, the migration will fail. If they change their password after the mailbox is migrated, new e-mail sent to their mailbox on the IMAP server will not be migrated to their cloud-based mailbox.
  • Don't delete mailboxes or change their SMTP addresses during migration   The migration system will report an error when it can't find a mailbox that's been migrated. Be sure to complete the migration before you delete or change the SMTP address of a cloud-based or on-premises mailbox that's been migrated.
  • Communicate with your users   Give users a heads-up that you are migrating the content of their on-premises mailboxes to your cloud-based organization. Consider the following:
    • Tell users that e-mail messages larger than 35 MB won't be migrated. Ask users to save very large messages and attachments to their local computer or to a removable USB drive.
    • Ask users to delete old or unnecessary e-mail messages from the on-premises 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 to back up their Inbox.
    • Tell users which folders won't be migrated.
    • Folders with a forward slash ( / ) in the folder name aren't migrated. If users want to migrate folders that contain forward slashes in their names, they have to rename the folders or replace the forward slashes with a different character, such as an underscore character ( _ ) or a dash ( - ).
    • Tell users when they can use their cloud-based account to access the e-mail that was migrated from their on-premises account. Don't give users access to their cloud-based accounts until you're ready to complete the migration. 
      Need a good way to provide users with information about their new cloud-based accounts? See Send a Welcome Message to New Users.


Microsoft Partner
Partner of Record Number 
2437508



Comments