Office 365 Setup | Tips For a Smooth Office 365 Migration
9
post-template-default,single,single-post,postid-9,single-format-standard,ajax_fade,page_not_loaded,,qode-theme-ver-14.3,qode-theme-bridge,disabled_footer_top,wpb-js-composer js-comp-ver-5.4.7,vc_responsive

Tips For a Smooth Office 365 Migration

Tips For a Smooth Office 365 Migration

Tips For a Smooth Office 365 Migration

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.

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

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

  • 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:

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

This should give you enough time to discover any post migration issues present.

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

  • 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.
No Comments

Sorry, the comment form is closed at this time.