Sean Wallbridge
I’m going to go out on a limb, here, and try to cut through some of the “fog” that surrounds email migrations to Office 365. While there are all sorts of scenarios based on individual situations, there are really only two ways that migrations happen from on-prem Exchange to O365; 1) use Microsoft tools with a Hybrid Exchange configuration (on-prem and O365 “know” about each other) or, 2) use third-party tools to perform the migration (on-prem and O365 don’t “know” about each other). Of course this is a simplification but it does boil it all done to the essentials.
The methodology you choose will have an impact on you going forward so you need to give it some thought before you (and your migration partner, if you use one) move forward with your migration.
The first thing you need to understand is the implication of a hybrid configuration. Hybrid implies that your on-prem Exchange and O365 Exchange know about each other. What this means in practice is that you essentially follow the process of standing up an additional Exchange server inside your domain even though the new Exchange server is in O365. The reason for this is simple: this is the traditional method for moving to another Exchange server or performing an Exchange upgrade so the process and all required bits and pieces already exist. What you may not know is that this process sets you up for a bit of a conundrum going forward. As of this writing (April 2015) there is no clearly defined or properly supported methodology from Microsoft for decommissioning the on-prem Exchange server after your migration is completed in a Hybrid scenario. This is not a problem if you are planning to keep the on-prem server around and there are valid reasons for doing so. However, if your plan was always to decommission the on-prem server then you have a problem. There are unsupported methodologies to decommission the on-prem server but as they are unsupported using them may lead to problems down the road inside O365.
Hence the existence of third-party tools to migrate to O365 Exchange such as those available from BitTitan and SkyKick (to name just two of many). These tools provide the mechanisms to migrate all of the data from the on-prem server to O365 without using the backend Microsoft tools and mechanisms that imply a Hybrid configuration. In some cases the third party tools do a better job than the Microsoft tools as they cover more bases than Microsoft does; SkyKick, for example, handles the migration of the user’s Outlook data brilliantly. Using these tools guarantees a “clean” configuration in O365 and nothing in your local domain that will prevent you from decommissioning your on-prem Exchange after the migration is completed.
Of course one of the considerations that will come into play is cost. Using the Microsoft tools is “free” while there is always a cost to using third-party tools. But keep in mind that the cost of migration is always going to be more than what it costs you to actually perform the migration; there are costs that may crop up down the road if you failed to plan properly. If you are prevented from using functionality in O365 or Azure because of an unsupported process that you used during the migration then your long-term costs may be much higher than what the initial third-party tool cost would have been.
As I said at the outset, there are all sorts of things you need to consider when planning your Exchange migration to O365 but the biggest single consideration has to be whether or not you are going to run a Hybrid configuration. Give serious consideration to this and get the information you need to make an informed decision. If you are working with a migration partner make sure they answer all your questions and ask to see their migration plan. A little sober thought beforehand can save you a lot of grief in the long run.