Migrating email from Exchange (on-premises) to Office 365 (in the cloud) would seem to be a pretty simple and straight forward process, and when you know what you are doing, it is a methodical process. However in the past 2-3 years that we've been doing Office 365 migrations, it's amazing the number of times we get called in to "fix something" that some other migration specialist did that has us shaking our heads wondering what they were thinking...
For this blog post, I've asked Ed Crowley, Microsoft Exchange MVP, Office 365 migration expert, and Convergent Computing (CCO) consultant to collaborate with me on what he's seen in terms of Office 365 migrations, being that he's literally migrated tens of thousands of mailboxes, and at times have had 5-6 migrations going on at the same time. When it comes to knowing Office 365 migrations, Ed's one of the best around!
First of all, when done right, an Office 365 Migration is like any other migration, there's planning that needs to be done, prerequisites that have to be configured, quirks that have to be worked out, and then ultimately just select mailboxes and migrate users to Office 365. Although as Ed has commented to me many times in the past, "there's no such thing as a standard or simple migration to Office 365." Every organization has something that can create a problem during a migration that might include:
- existing Exchange environment has corruption and stability issues - those need to be worked out or just taken in account during the migration process
- no downtime allowed - we'll occasionally come across orgs where employees (executives frequently) that cannot be "down" on email (ever), again, commonly seen and best practices developed to address that
- slow network connection - which slows the upload of Exchange emails up to Office 365, but there are ways to address that in terms of "staging" mail migration of content so that an initial sweep COPIES emails up to Office 365 over a few days / weeks, and then subsequent mail sweeps copies over any new messages/changes, and then ultimately a final sweep that migrates any most recent messages and cuts the mailbox over
- intense security - we've walked into orgs where security is so clamped down that many of the default tools and processes from Microsoft to migrate to Office 365 have to be tweaked to fit within the security guidelines of the organization. Have yet to find blockers, but what could take 2 hours can take 2-3 days (if you know what you're doing relative to security) to just work within the guidelines of some organization's security department
- misconfigured firewalls, proxy devices and CAS servers - a corollary to the last point, boundary protection that's misconfigured can corrupt Exchange Web Services, Autodiscover and SMTP traffic to where a hybrid configuration simply doesn't work at all or is broken in some way
- old Outlook clients - so Office 365 has rolling requirements for what is supported for users, currently it's Outlook 2007 SP3 or higher for Windows systems, and Entourage for Mac 2008 with SP3 or higher. But we've run into orgs where they had business processes built on Office 2003 and can't upgrade past 2003, so we've come up ways to get to Office 365, yet still address these old endpoint client systems. In addition, organizations often forget that they must deploy the Microsoft Online Sign-In Assistant with old clients. In general, it's best to upgrade users to Outlook 2013 before or when their mailboxes are moved for the best user experience.
- legal and compliance policies - moving email "to the cloud" is new for organizations, and there are always tons of questions about addressing security and especially adhering to regulatory compliance policies like the European Union Data Protection Directive, or HIPAA, or the like. I think by now we've heard them all, and have address them all, but something that comes up and we are familiar addressing
- tenancy name not available — employees of a company will frequently obtain a trial of Office 365 and forget about it. When it comes time to obtain the production tenancy, the desired tenant name (companyname.onmicrosoft.com) is taken (used and discarded in a trial a while ago) and Microsoft Online Support is not of much help in getting that tenancy name back
- no administrative method — we have assisted organizations who use Directory Synchronization but don't have an on-premises Exchange server with which to update and create new users, groups and contacts. Using ADSI Edit is not a sustainable method of managing recipient properties
- some quirky 3rd party plug-in to Exchange - There commonly is some weird fax software, voicemail software, integration tool to other server apps, email archives sitting in Enterprise Vault or EMS or the like, again, all common things that come up, just have to identify the item(s) and work them into the migration plan
Sign up for CIO Asia eNewsletters.