Email migration paths from SBS/Exchange to Office 365

Whether you are a small business migrating from SBS Server 2003, 2008 or 2011, or a mid-sized business operating with Exchange On-premises (or even if your email system is hosted), there is probably a migration path available for you.

Here are various methods you would have to choose from based solely on what version or type of source environment you’re coming from.

I actually left out IMAP here, which also supports certain hosted systems; it is otherwise similar in features to the Cut-over method–however, I almost never use it. Most commonly, my job involves moving customers from legacy Exchange environments such as 2003, 2007 or 2010. And that means I am nearly always leaning toward a Remote Move migration.

Comparing migration methods

I purposefully arranged the various methods from most preferred to least preferred. And you can probably see why–there are far more “NO’s” in the right-most options.

Remote Move

Remote Move is great because it is fairly easy to set up, and does not require additional expenditure (like third-party tools). Contrary to popular rumor, it does NOT require an ADFS server implementation. It also offers a very “low-touch” migration experience, similar to what you get with a third-party option. In short: you don’t need third party tools to have a great migration experience with this method.

From the end-user perspective: it just works. Close & reopen Outlook, done.

From the admin’s perspective: also easy!

1. Prepare for the migration
2. Configure Directory Synchronization
3. Create the hybrid connection
4. Create Remote Move migration batch
5. Migrate Public Folder data (if applicable)
6. Finalize the migration batch & activate mailboxes
7. Complete Office 365 setup & cutover DNS
8. Post-migration tasks

Exchange Server 2010 or 2013 is required. So you can natively do this migration from SBS 2011 or Exchange 2010. If you have an older server like SBS 2008 / Exchange 2007, you can still install an Exchange 2013 server (for free!) and migrate using Remote Move. In the end, your hybrid Exchange server can stay in-place for management & local relay purposes, or be removed–your choice.

Third-party tools

I’ve become lazy. I used to reverse the preference here and choose Cutover migration if Remote Move wasn’t possible. These days, I find it is worth my time to absorb some expense, and save myself the hassle of touching dozens of computers or supporting a self-service method. The tool I am personally most familiar with is SkyKick, which I believe is only available to Microsoft Partners, though there are others out there.

Some notes from my experience:

• You can bring your own Office 365 subscription to the table, or sign up through SkyKick
• Works with or without Directory Synchronization (there are some additional steps if you are using it however)
• SkyKick sends out automated communications to the end-users (which are non-optional, and non-editable)
• Automatically alerts you to issues with workstation configuration
• Automatically configures new Outlook profiles, including autocomplete, PST’s, etc. with about 98% success rate
• You can turn over DNS control, though I prefer to hold onto it and make the changes myself
• Some AD/DNS & Exchange settings may still need to be manually modified in the source server during cut-over (third-party vendors provide good documentation for this)
• Mobile devices will still need to be manually reconfigured (instructions sent out to users in advance)
• A quasi-technical person could probably manage this migration

Cutover, IMAP and manual (PST) migrations

I suspect at least a few of my compatriots out there will shy away from the expense of third-party tools, and go with more manual-style migrations instead, especially if they are coming from older Exchange systems such as 2003 or 2007.

When it comes time to cut over DNS records, users will need to set up brand new Outlook profiles–manually. That means you also have to take care of stuff like rules, signatures, auto-complete, PST’s and so forth. Self-service is the preferred way to deal with this–having each user export everything in advance, and then re-import on cut-over day.

1. Prepare for the migration
2. Enable Directory Synchronization (optional)
3. Migrate mailbox data
   • Create a migration batch in Exchange Online OR
   • Export Outlook settings & data including Public Folders (optional)
4. Finalize the migration batch & activate the mailboxes
5. Complete your Office 365 Setup and cut-over DNS
6. Changes to on-premises Active Directory and Exchange
7. Add SMTP relay connector (if applicable)
8. Create new Outlook profiles, import data & settings
9. Reconfigure mobile devices
10. Post-migration tasks

The details behind these steps can be found here, in this post.

Whether you do it for them, or they do it themselves, the cutover experience is just a bit more painful for everyone involved. If you have very few users, or tech-savvy ones, then this might not be so bad for you. But like I said, I’ve been spoiled on the fanciness of Remote Move and third-party tools, so these other migrations just make me cringe a little. And then I remember that my time is worth more to me than the cost of a third-party tool. And I feel better again.