In-Depth

10 Steps for Ensuring a Smooth Migration from Exchange Server to Office 365

Migrating from traditional on-premises e-mail to the growing Microsoft cloud can be easier with this game plan.

• By Brien Posey
• 04/01/2015

Many organizations are gravitating to the lure of giving up running Exchange Server in favor of turning it over to Microsoft Office 365. The Exchange Online offering in Office 365 is much easier to manage, eliminates the capital cost associated with running the Server edition and the management overhead associated with it.

At the same time, anyone who has performed an Exchange Server to Office 365 migration will tell you doing so is a complex undertaking. Even the cutover migration method, which is designed to be relatively easy, requires extensive planning. Needless to say, the potential exists for things to go wrong during the migration process.

Fortunately, there are some things you can do to hedge your bets and improve your chances of a smooth migration.

1. Choose an Appropriate Migration Method
Perhaps the single-most-important thing you can do to ensure a smooth migration to Office 365 is to choose an appropriate migration method. Some of the marketing hype surrounding Exchange Server migrations to Office 365 might lead you to believe the migration process can be completed in six easy steps. In reality, only the smallest organizations can get away with these simplified migrations. Microsoft supports three primary migration types.

The first type is a cutover migration. Cutover migrations are designed to be easy, but can only be used in Exchange Server organizations with less than 1,000 mailboxes. However, cutover migrations might not always be the best choice, even for small organizations, because the migration must be completed all at once. If the users have excessively large mailboxes, then a cutover migration might take an unacceptable amount of time to complete.

The second type supported by Microsoft is an IMAP migration. An IMAP migration is designed primarily for situations in which mailboxes are migrated from a non-Exchange mail system to Office 365. IMAP migrations can sometimes be used as a shortcut for migrating mailboxes from outdated Exchange Server versions (Exchange 2000 and newer are supported), but IMAP migrations are incapable of migrating anything other than e-mail messages. Consequently, contacts, calendar items and tasks are lost during the migration process.

The third primary type supported by Microsoft is a hybrid migration. It's the most flexible migration type, but it's also the most complicated. A hybrid migration requires the Exchange admin to create a hybrid Exchange Server deployment by establishing coexistence between the local Exchange Server and Office 365. Hybrid migrations are usually the only migration method suitable for use by larger organizations.

2. Estimate the Time Commitment as Accurately as You Can
To ensure a smooth migration, try to estimate the amount of time the migration process will take. If you're performing a hybrid migration, then you'll be able to migrate users in batches. Even so, you don't want to make the batches so large it takes an unreasonable amount of time for the migration batch to complete.

Microsoft provides a chart outlining the average throughput you should expect during an Office 365 migration. A staged migration often experiences an average throughput of 10GB to 14GB per hour. Even so, there are a number of factors that can impact the actual throughput. For instance, the amount of WAN bandwidth you have available is a major factor. There are also three different types of throttling that can make a difference:

• Office 365 User Throttling: Designed to adjust user sessions by regulating client access protocols such as RPC over HTTP. This type of throttling tends to impact third-party migration tools and client upload-based migrations.
• Office 365 Migration Service Throttling: Places limits on the number of mailboxes you can migrate simultaneously. The default throttle value is 10, but the throttle can be adjusted to meet your needs.
• Office 365 Resource Health-Based Throttling: The least restrictive type of throttling. It only comes into play when Office 365 is experiencing service degradation issues. If the service is degraded to the point where users experience performance problems, then the migration process will be put on hold until an acceptable level of performance is restored.

3. Don't Skimp on the Migration Infrastructure
If you're planning to perform a staged migration, there are some infrastructure requirements to which you'll have to adhere. For starters, you'll need a server running Active Directory Federation Services. This server handles identity management between the two environments. You're also going to need a migration server to facilitate the migration process. It's important both of these servers be sufficient to accommodate the required workload.

Technically, the migration server can run on virtual hardware, but using a virtualized migration server tends to result in performance problems, except in smaller organizations.

Microsoft recommends larger organizations use physical, enterprise-class hardware for Exchange 2013 and 2010 hybrid servers. In tests, the following hardware configuration yielded a consistent 30GB-per-hour throughput:

• Network: 500MB outbound pipe to the Internet; internal network on 1GB with a 10GB fiber backbone.
• Hardware: The specifications for the two client access/HUB (physical) servers are:
• CPU: Intel Xeon CPU E5520 at 2.27GHz and 2.26 GHz (two processors)
• RAM: 24GB
• Disks: Eight at 146GB per disk; RAID 5 configuration equals 960GB total raw space
• MRSProxy: Configured with a concurrency of 100

4. Use a Multi-Stage Pilot Migration
If you're migrating mailboxes from local Exchange Servers to Office 365, it's a good idea to plan for a pilot migration program. However, I'd recommend taking things a step further and putting a multistage pilot migration plan into place.

The first stage of this pilot migration program could be considered to be nothing more than a migration test. You might, for example, create a few test mailboxes, load them up with messages, calendar entries, contacts and tasks, then use those mailboxes to test your migration plan.

If everything goes well with migrating your test mailboxes, you should then migrate a representative sampling of your production mailboxes. It's a good idea to avoid migrating mailboxes belonging to anyone who performs a critical job function, at least for now. The goal behind this phase of the pilot migration is to once again verify your migration technique and make sure users are still able to work effectively after the migration completes.

I recommend waiting several weeks after the pilot migration to begin migrating everyone else. This should give you enough time to discover any post migration issues present.

5. Be Aware of Impacting Existing Functionality
Depending on what version of Exchange Server you're currently running, the migration process may impact Exchange Server functionality in various ways. One common issue occurs with mailboxes residing on Exchange 2003, where servers are inaccessible throughout the duration of the migration.

Sometimes it isn't the migration process itself that impacts functionality, but rather what happens after the migration completes. For example, the migration process can break free/busy calendar sharing. For example, suppose an organization were to establish calendar sharing with another Exchange Server organization that uses a hybrid deployment consisting of on-premises servers and Office 365. In this type of situation, free/busy lookups will fail for any mailbox already migrated to Office 365. The reason for this is the free/busy sharing relationship established in this case is between two local Exchange Server organizations. There was never a free/busy relationship established with Office 365 and Exchange Server 2013 isn't capable of proxying free/busy requests to Office 365 servers. Microsoft has published a workaround for this problem.

6. Be Aware of Version-Specific Nuances
The migration process is at least somewhat straightforward if the organization is running Ex-change Server 2007 or newer. However, organizations running older versions of Exchange Server must determine how their current Exchange Server version will impact the migration process. Essentially, organizations have two choices. They can perform a two-step migration or they can work within the limits of their current Exchange Server version.

A two-step migration involves migrating to a newer Exchange Server version prior to migrating to Office 365. For instance, an organization might migrate from Exchange Server 2003 to Exchange Server 2010. This is usually the preferred method because older versions of Exchange Server can pose significant migration challenges.

Exchange Server 2003 mailboxes, for instance, are inaccessible for the duration of the migration process. Worse yet, the migration process is very sensitive to poor network performance. If the migration process is interrupted, it must be restarted. It cannot be resumed from the point of interruption. This leads to a longer period of time during which mailboxes cannot be accessed.

7. Verify Your Organizational Readiness
Preparing for a staged migration is a complex undertaking. If an organization hasn't properly prepared its local Exchange Server deployment, the migration process may fail. Hence, it's extremely important to make sure your Exchange Server organization is properly configured before you begin the migration process.

Thankfully, Microsoft provides a tool you can use to assess your organization's readiness. The tool is included with Office 365 and is called the Office 365 Health, Readiness and Connectivity Checks tool. This tool (see Figure 1) can either perform a quick check of the most important readiness aspects, or it can be used to conduct a much more comprehensive (and time consuming) readiness assessment.

8. Don't Forget About the Clients
While you're preparing for an Office 365 migration, it's important to verify client readiness. If you're planning to let your users access their mailboxes through Outlook Web App then verifying client readiness is as simple as verifying browser compatibility.

If you plan to connect users to their mailboxes by using Outlook, then you'll have to perform a software inventory as a way of making sure compatible versions of Outlook are in use throughout the organization. Outlook 2003 isn't supported for use with Office 365.

Microsoft generally recommends using Outlook 2010 or Outlook 2013 for Office 365 connectivity. In some instances, Outlook 2010 may require manual configuration in order to connect to a user's mailbox. As such, you should plan to do some testing ahead of time so you can anticipate any connectivity problems that might arise after a user's mailbox has been migrated.

9. Take Your Time with Staged Migrations
There's no rule that says you have to perform a staged migration quickly and then immediately deprovision your local Exchange Server environment. To the contrary. You can maintain coexistence between your local Exchange Server environment and Office 365 Exchange for as long as you want. Even permanent coexistence is acceptable.

Of course, functionality isn't the only consideration. Some administrators have been pressured by their superiors to complete the migration and deprovisioning as quickly as possible. The reasoning behind this pressure is hybrid Exchange Server environments involve two complete Exchange Server organizations (the local Exchange organization and the Office 365 Exchange organization). This means there's a higher degree of complexity than a single Exchange organization, which leads to a greater potential for problems and higher support costs.

In spite of this, it's important to remember hybrid Exchange Server deployments have been well tested by Microsoft and are fully supported. As long as an organization adheres to Microsoft best practices, a hybrid Exchange deployment is unlikely to be problematic. That being the case, it would be ill-advised to rush the migration process. It's better to spend time getting to know the Office 365 environment and all of its nuances before decommissioning your local Exchange Server environment.

10. Use the Right Tools for the Job
You should also take advantage of the available tools to make the migration process easier. Microsoft provides some decent tools for migrating Exchange Server mailboxes to Office 365. I already mentioned the Office 365 Health, Readiness and Connectivity Checks tool, but there are others. The Microsoft Exchange Server Deployment Assistant (Figure 2) asks you questions about your migration and creates a migration plan for you.

There are also third-party tools available to make the migra­tion process easier:

• Metalogix Cloud Acceleration Suite for Office 365
• Dell Migration Manager for Exchange
• Binary Tree E2E Complete

Although some are on the more expensive side, these tools may very well be worth the cost, especially for organizations performing large-scale migrations