This is the second part of my discussion about methods of migrating from on-premise Exchange to Office 365.<\/p>\n
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 \u201cpushing\u201d the data up to 365.\u00a0 The rest of the discussion will be about migration strategies that don\u2019t rely on Outlook as the migration conduit.<\/p>\n
There are two basic migration strategies that you can consider when you are looking at migrating larger numbers of users to Office 365.\u00a0 The first strategy relies on running your on-premise Exchange and Office 365 in a hybrid mode<\/em><\/strong>.\u00a0 The core of a hybrid mode is the fact that your on-prem Exchange and Office 365 \u201cknow\u201d about each other and freely exchange data.\u00a0 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.\u00a0 In essence the two email servers act as one overall larger email server where user mailboxes can live on one of the two servers \u2013 mine is here, yours is there \u2013 and there is some very smart routing in place between them so that the outside world isn\u2019t aware that there is more than one server involved.\u00a0 The built-in migration tools in Office 365 rely on this scenario.\u00a0 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.\u00a0 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<\/em> be shutdown at the end of the migration.\u00a0 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.\u00a0 There are some third-party developed guidelines out on the \u2018Net that describe a process but they are neither sanctioned nor endorsed by Microsoft.\u00a0 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.<\/p>\n 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<\/em> making the direct linkages between the on-prem server and Office 365 that are made in the hybrid scenario.\u00a0 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.\u00a0 While it may sound like a straight-forward process I can assure you that it isn\u2019t and there are many ways of getting there and many third party vendors with tools to make the journey.\u00a0 Some tools can migrate everything including Public Folders, some tools can only migrate users.\u00a0 Some tools allow you to \u201cstage\u201d migrations in groups, some tools force you into a \u201cbig bang\u201d migration.\u00a0 But the end result should be that your data is migrated into Office 365 without any direct \u201clinkage\u201d being put in place between your on-premise Exchange and Office 365.\u00a0 This then means that the on-premise Exchange can be shutdown and removed from your local AD post migration.<\/p>\n The best strategy is to understand what your organization\u2019s requirements are and plan accordingly.\u00a0 Trust me when I say that you can\u2019t just throw together a migration to Office 365, doing so is to plan for failure.\u00a0 You need to understand where you are going then use the best tools to get there.\u00a0 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.\u00a0 Make sure you understand what the end goal is before you start planning your migration.\u00a0 Also understand that in the migration game you truly get exactly what you pay for!\u00a0 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.\u00a0 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.\u00a0 The \u201cbetter\u201d 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.<\/p>\n 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.\u00a0 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.\u00a0 But even with all that it does we see lots of time being used up with end-user issues; their issues at the \u201cend\u201d of the cutover process actually eat up more time than the work involved to prep and perform the migration itself!\u00a0 This is not a fault of the process or the tool; it is simply the fact that we humans are \u201cmessy\u201d and pretty bloody awful at following directions.\u00a0 So plan accordingly and double or even triple your time budget to handle the end-user issues.\u00a0 Microsoft and the various tools vendors always plan for \u201cproper\u201d use of Outlook and, by extension, Exchange and Office 365.\u00a0 Your users will show you weird and wonderful situations with their Outlook that will \u201ccontravene\u201d all the \u201cproper\u201d scenarios that Microsoft et al have planned for.\u00a0 So be prepared!<\/p>\n<\/h2>\n
Best Strategy<\/h2>\n