Is a hybrid Exchange deployment the right option for you?

One decision to make when moving to Office 365, is determining how to move mailboxes. There are various options available and this makes it hard to see the forest through the trees. And choosing the right approach is no easy task. The decision is influenced by many variables such as the size of your organization, the impact on your users, the impact on your IT department, and the bandwidth of your internet connection.

Before we address the question of whether or not you should go down the road of a hybrid deployment, let's quickly review the options that are available to you today. Please note that the descriptions below are not intended to cover all aspects of each approach, rather to paint a picture of the current landscape:

• Cutover migration. As the name implies, this approach is used to 'move' all mailboxes from your on-premises organization to Office 365 at the same time. At least, the switch to Office 365 happens at the same time. Prior to switching to Office 365, mailbox contents are copied to Office 365. Depending on the amount of mailboxes and the size of the mailboxes you are migrating, the copy process can take several days, if not weeks. During that time, your users continue to use their on-premises mailbox. Once the initial copy process has completed, delta synchronizations keep the mailboxes in Office 365 up-to-date with new contents from the on-premises mailboxes until you switch over to using the Office 365-based mailboxes. During the switch over time (also referred to as the cutover), all your users must reconfigure their email clients to point to Office 365 instead the on-premises organization.
• Staged migration. This approach allows you to migrate your users in batches to Office 365 and can be handy in larger environments where the cutover migration approach is not an option. Although, theoretically, a cutover migration can be used for up to 2,000 mailboxes, having to manage the switch to Office 365 for such a large user population can be quite challenging. Having smaller batches of users to manage is definitely easier for the IT department to manage. Inevitably this means that during the transition to Office 365, you will have users in both the on-premises environment and in Office 365 which creates the need for some sort of coexistence between both environments. In a staged migration, this coexistence is limited to mail flow only. This means that users can mail one another, but they cannot see each other's free/busy. Similar to the cutover migration approach, migrated users will have to reconfigure email clients to point to Office 365 instead.
• Hybrid deployment. A hybrid deployment stands for a full fidelity migration. What this means is that of all the migration options, the remote mailbox move (which comes as a feature of a hybrid deployment) is the only one that allows you to seamlessly move a mailbox to Office 365: after the mailbox move is completed, the user's Outlook profile is updated automatically. During the migration period, users can almost seamlessly work together too. Just like the staged migration, they can email one another, but they can now also see each other's free/busy information. All this sounds great, but the benefits of a hybrid deployment come at a cost: a hybrid deployment is usually more complex to setup and to maintain than the alternative migration approaches outlined earlier.
• 3^rd party tooling. 3^rd party tools are a great way to solve migration issues which neither of the aforementioned approaches can. For instance, 3^rd party tools can be a very flexible way to move from non-Microsoft or hosted messaging platforms to Office 365, such as Gmail. In theory, the cutover migration also allows you to connect to Gmail using IMAP. But, without going into details, there are some limitations to using the IMAP migration option. Often, these 3^rd party tools take away complexity from the migration, by taking care of the more complex stuff for you. Of course, these tools do come at an additional cost, whereas any of the three aforementioned methods are free; at least from a licensing standpoint…

Now that we have reviewed the different options, let's return to the main question: is a hybrid deployment the right choice for your organization? You might argue that I'm a little biased on the subject as I've been dealing with hybrid deployments for the better parts of the past few years. The truth is that that there is a reason why I've been dealing with hybrid deployments that much: it's simply the most flexible migration option that is available today. This doesn't mean that I would recommend a hybrid deployment to a customer with 25 users.

When considering a hybrid deployment, there are a lot of factors that come into play. First, and foremost, you must be able to muster the complexity of a hybrid deployment. Configuring a hybrid deployment – running the Hybrid Configuration Wizard – is not the problem here, it is the other components such as directory synchronization. The implications of having directory synchronization enabled are far greater. When directory synchronization is enabled, on-premises objects are synchronized to Azure Active Directory. The on-premises objects are considered to be the source of authority which means that changes to objects must be made through the on-premises organization. For example, this means that if you create a new mailbox or update mailbox properties, these changes have to be executed in the on-premises organization –using the on-premises tools. In an environment where the hybrid configuration is used to indefinitely keep some mailboxes on-premises and other mailboxes in Office 365 this is not much of a problem as an on-premises Exchange environment still exists.

But how about an organization that just moved all its mailboxes into Office 365? Today, you have to keep at least a single on-premises Exchange server for administration purposes if you have directory synchronization enabled. Theoretically you can work around this requirement by managing objects directly through Active Directory. However, doing so yourself or using a 3^rd party tool that does it for you, isn't officially supported…. For many it doesn't make sense having to keep a server if all what you are trying to do is to get rid of them in the first place. But it's a consequence of how things work today. I have no doubt that in the future Microsoft will "solve" the problem. But we're not there yet…

This being said, many organizations decide to enable directory synchronization for other reasons. One of the biggest, and most important arguments is that directory synchronization removes the need to manage objects in two environments.

Truth be told, directory synchronization isn't the most important reason why people (don't) choose the hybrid approach. As mentioned earlier, a hybrid configuration is the only approach that allows you to move mailboxes back into the on-premises environment with the same ease to move it into Office 365. So, while the hybrid deployment gives you the ability to move to Office 365, it immediately provides you with a back-out plan. Especially if you are still “dipping your toe in the water,” this is a perfect argument.

Additionally, the native mailbox moves in a hybrid deployment happen 'online' and are almost fully transparent to the end user. Except for a few restarts of Outlook, a user won't notice that his mailbox was moved to Office 365. That is quite different from having to instruct them on how to update or recreate the Outlook profile… Outlook isn't always the largest concern. Mobile devices are just as important, if not more important these days. In a cutover or staged migration, mobile devices using Exchange Active Sync (EAS) must be reconfigured. Since the latest Cumulative Update for Exchange 2013, this is no longer the case in a hybrid deployment. Most mobile devices will now automatically update their profile. This is not only a benefit for end-users, but also for the IT department which has to support those users. It takes away a huge amount of work during migrations. If you are using some sort of mobile device management platform, you can argue that the platform can take care of device reconfiguration. And while that is true, it still involves making sure the configuration changes are pushed which costs more time than just having the clients update the next time they try to connect to their mailbox.

From a technical perspective, the native mailbox moves also prove to be more attractive than the other migration options, much for the same reason of not requiring a resynchronization of the offline Outlook cache (OST). The best way to explain this is through the following example: you move a 5GB mailbox to Office 365 in a hybrid deployment. After the 5GB has been transferred (over the internet), the user's Outlook profile is reconfigured to point to Office 365. In a staged or cutover migration, the 5GB that was uploaded now needs to be downloaded again because of the OST file resynchronization. That is, assuming you don't use Outlook 2013 built-in slider to limit the amount of data that is kept in the cache. Regardless of this, the downside of the other migration approaches is that they require data to be downloaded again. In a staged migration this can be a controlled process because you decide how large a migration batch is. The same is not true for a cutover migration. When the cutover is performed, all Outlook clients will resynchronize their content at approximately the same time, unless you have clients connect to their new mailbox in waves... If you have an internet connections that is large enough, you might be able to deal with the additional load. But what if you are in a remote area and you only have a 5Mbps connection to the internet…?

Another strong argument for a hybrid connection is the ability to migrate public folders or allow cross-premises access to public folders. Neither the cutover migration nor staged migration process allow you to do that.

I don't want to paint the picture that a hybrid deployment will solve all your problems. It won't. I'm just saying that it's a very flexible way of migrating users to Office 365… Ultimately it's up to you to compare the efforts and complexity of setting up a hybrid deployment to the benefits it provides and then decide if the limitations of the other migration approaches are something you can deal with or not. If you can live with those limitations, then I would certainly have no problem recommending going down that road instead.

Exchange Hybrid and Office 365 Monitoring and Reporting

On-premises components, such as AD FS, PTA, and Exchange Hybrid are critical for Office 365 end user experience. In addition, something as trivial as expiring Exchange or AD FS certificates can certainly lead to unexpected outages By proactively monitoring hybrid components, ENow gives you early warnings where hybrid components are reaching a critical state, or even for an upcoming expiring certificate. Knowing immediately when a problem happens, where the fault lies, and why the issue has occurred, ensures that any outages are detected and solved as quickly as possible.

Access your free 14-day trial of ENow’s Exchange Hybrid and Office 365 Monitoring and Reporting today!