This article is an excerpt from the book “Office 365 for Exchange Professionals”.
Office 365 supports a variety of migration methods that customers can use. The choice of migration method can be influenced by a wide range of factors such as the number of objects involved in the migration, the amount of data to be moved to Office 365, the version of Exchange Server (if any) running on-premises, long-term migration or co-existence requirements, whether the organization uses non-Exchange email servers, and even the budget available to spend on the migration project.
The migration methods that are available are:
- Cutover migration
- Staged migration
- Hybrid configuration
- IMAP migration
- Third party migration tools
The best place to start is with the business requirements of the migration project. The business requirements should include factors such as the need to complete the migration by a particular date, whether a back-out option for the migration needs to be included, or whether some email resources will remain on-premises. As you will see when you read through this chapter, each migration method has different benefits and constraints, and they may not all suit the business requirements of the project.
The next items to consider are the technical requirements, as they will often quickly eliminate some of the migration methods and allow the organization to zero in on the approaches that are actually possible for them to use. The diagram below provides an example of the decision making process you can work through based on your technical requirements to understand the available migration methods for your scenario.
The decision making process begins by asking whether the on-premises environment runs Exchange Server 2003 or 2007. For those environments the next decision point is whether there are more than 2000 mailboxes. Organizations with fewer than 2000 mailboxes are supported for cutover, staged and hybrid migrations, whereas more than 2000 mailboxes are only supported for staged or hybrid migrations.
Real World: Although 2000 mailboxes is the threshold specified by Microsoft in terms of support for cutover migrations, it doesn’t mean that organizations with up to 2000 mailboxes should only consider a cutover migration. The logistics involved in handling an outage for a large number of users, as well as the desk-side support needed to assist with reconfiguring Outlook profiles and mobile devices after the cutover, may simply make a cutover migration too risky and complex for the organization. In fact, many experienced Office 365 consultants consider the practical limits of both the cutover and staged migration methods to be more like 150 mailboxes. Organizations larger than 150 mailboxes should give strong consideration to using a hybrid migration instead of a cutover or staged migration.
The 2000 mailbox limit doesn’t mean that organizations with less than 2000 mailboxes should automatically choose a cutover migration. For example, if the organization wants to migrate their users in smaller batches instead of one big batch then a cutover migration would not be suitable.
When cutover is either not possible or not desirable for an Exchange Server 2003/2007 organization the remaining options are staged and hybrid migrations. For an Exchange Server 2003 environment a migration to Exchange Server 2010 needs to be completed first. For an Exchange Server 2007 environment at least one Exchange Server 2010 or 2013 server must be installed in the organization to provide the hybrid functionality. Both options require directory synchronization to be implemented. Without directory synchronization, your migration options are limited to third party tools.
An organization running Exchange 2007 or higher can choose to take advantage of the free “Hybrid Edition” license available from Microsoft. This allows an Exchange Server 2013 or Exchange Server 2010 SP3 server to be deployed in the organization to host a hybrid connection with Office 365. The Hybrid Edition license can’t be used for a server that hosts mailboxes, but the server can be used during the migration to Office 365 and retained afterwards for managing the Exchange attributes of the on-premises Active Directory objects, and can also be used as an SMTP relay server for applications or devices on the corporate network.
If the implementation of a Hybrid Edition server is not possible, for example due to server capacity constraints, then a staged migration is the way forward.
The staged migration method is not available for organizations that run Exchange Server 2010 or 2013. The same 2000 mailbox support limit exists for cutover migrations, so smaller Exchange Server 2010/2013 environments can still choose to perform a cutover migration. However as we’ve already discussed, large cutover migration projects can be logistically very difficult to perform.
Given that Exchange Server 2010 and 2013 are both capable of hybrid configuration with Office 365 you should give strong consideration to hybrid instead of staged or cutover. Although this is the most complex of all of the migration options, it also delivers the best user experience. Hybrid configurations allow the on-premises Exchange organization and Office 365 to function as though they are the same environment with seamless mail flow, a shared address book and calendar free/busy federation. In fact, most users would not even be aware that they are working in a hybrid configuration with mailboxes deployed in both on-premises and Office 365. A hybrid configuration is also the only option that allows mailboxes to be off-boarded from Office 365 to Exchange on-premises without using third party migration tools.
Hybrid configurations rely on directory synchronization. If for some reason the organization can’t implement directory synchronization then the choices are limited to third party migration tools.
Finally, businesses using non-Exchange email platforms can’t use the cutover, staged or hybrid options. For those businesses Microsoft provides an IMAP migration option for moving mailboxes to Office 365, or alternatively a third party migration tool can be used.
As you can see, the decision making process requires careful consideration even just for the technical requirements. Beyond that there are also other factors such as whether the migration project will be handled in-house or by an external consultant, whether extra training is required for IT staff to understand new features such as hybrid configurations, and whether funding is available to pay for third party migration tools if native migration options can’t be used.
Note: Before you finalise your decision on which migration method to use it is strongly recommended that you read through the example migrations in this book from start to finish so that you can learn about any risks or timing issues that you need to be prepared for. Do not start a migration before you have read through the process from start to finish at least once. You should also consider creating a test environment and signing up for a separate Office 365 trial tenant so that you can perform a hands-on test run of your chosen migration method.
