Sean Wallbridge
This is the second part of my discussion about methods of migrating from on-premise Exchange to Office 365.
In the first part of the discussion I identified some key things you need to know about Exchange and Outlook and I described the simple migration methodology of using PST files to move data between your old, on-premise Exchange and Office 365 by connecting a PST file to Outlook and “pushing” the data up to 365. The rest of the discussion will be about migration strategies that don’t rely on Outlook as the migration conduit.
Two Basic Strategies
There are two basic migration strategies that you can consider when you are looking at migrating larger numbers of users to Office 365. The first strategy relies on running your on-premise Exchange and Office 365 in a hybrid mode. The core of a hybrid mode is the fact that your on-prem Exchange and Office 365 “know” about each other and freely exchange data. If you have ever performed a migration upgrade between, say Exchange 2007 and Exchange 2010 on-prem, then you will already have a feel for the concept. In essence the two email servers act as one overall larger email server where user mailboxes can live on one of the two servers – mine is here, yours is there – and there is some very smart routing in place between them so that the outside world isn’t aware that there is more than one server involved. The built-in migration tools in Office 365 rely on this scenario. Migration occurs as a mailbox data move between the on-prem server and Office 365 in the backend and various mechanisms then handle the routing of user email as the process progresses. The key takeaway, here, is to understand the on-prem server and Office 365 become pretty entwined and that there is an expectation the on-prem server will not be shutdown at the end of the migration. As of this writing (July 2015) Microsoft has not published any clear guidelines on how to completely shutdown and remove an on-prem Exchange server after a hybrid migration has been performed. There are some third-party developed guidelines out on the ‘Net that describe a process but they are neither sanctioned nor endorsed by Microsoft. There can be valid reasons for wanting to leave the on-prem Exchange server in place but it can come as a nasty shock if you had not planned on this up front.
The second strategy is to use a third party tool that performs all of the migration work for you, in the background in a fashion similar to a hybrid migration, but without making the direct linkages between the on-prem server and Office 365 that are made in the hybrid scenario. In simple terms, the tool needs to be able to create/re-create all the user accounts in Office 365 and then populate them with all of the data that lives inside each user account in the on-premise Exchange. While it may sound like a straight-forward process I can assure you that it isn’t and there are many ways of getting there and many third party vendors with tools to make the journey. Some tools can migrate everything including Public Folders, some tools can only migrate users. Some tools allow you to “stage” migrations in groups, some tools force you into a “big bang” migration. But the end result should be that your data is migrated into Office 365 without any direct “linkage” being put in place between your on-premise Exchange and Office 365. This then means that the on-premise Exchange can be shutdown and removed from your local AD post migration.
Best Strategy
The best strategy is to understand what your organization’s requirements are and plan accordingly. Trust me when I say that you can’t just throw together a migration to Office 365, doing so is to plan for failure. You need to understand where you are going then use the best tools to get there. There are a lot of reasons to use a hybrid strategy just as there are a lot of reasons to not go hybrid and to use a third party tool. Make sure you understand what the end goal is before you start planning your migration. Also understand that in the migration game you truly get exactly what you pay for! There are very inexpensive migration tools available and there are some reasonably expensive tools available (most tools charge a fee based on user and/or mailbox count) and there is not much comparison between them. Keep in mind there is a lot more to a migration than just moving the data, you need to be able to manage the whole user experience. The “better” tools help with the user experience portion and I can tell you unequivocally the user experience portion of a migration is the black hole that will eat your time budget.
We (itgroove) have been migrating a large customer with a complex and intertwined group of email domains to Office 365 over the past two months with the migration being performed in stages. We are using SkyKick as the migration platform (available only through partners, not an end-user tool) and it does an incredible job of managing all the aspects of the migration. But even with all that it does we see lots of time being used up with end-user issues; their issues at the “end” of the cutover process actually eat up more time than the work involved to prep and perform the migration itself! This is not a fault of the process or the tool; it is simply the fact that we humans are “messy” and pretty bloody awful at following directions. So plan accordingly and double or even triple your time budget to handle the end-user issues. Microsoft and the various tools vendors always plan for “proper” use of Outlook and, by extension, Exchange and Office 365. Your users will show you weird and wonderful situations with their Outlook that will “contravene” all the “proper” scenarios that Microsoft et al have planned for. So be prepared!
Office 365 is a dynamite platform and there is so much that you can do with the tools provided once you are there. Don’t sour the user experience with an ill-planned migration. Do your homework, investigate the tools and know your environment before you start. Create your plan, do your prep, communicate well with all concerned and execute. And then enjoy the fruits of your labours!