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...
I 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
So these are the more common things that come up and have to be addressed. Again, have done SO many Office 365 migrations that we know to expect these things, we ask about them, we address the issues, and then we map out our plan to have a successful migration to Office 365.
BUT, for some of the more notable quirks that we've been pulled in to "fix" from migrations in progress that needed our assistance:
- SLOW Mailbox Migration: We've run into a handful of migrations where the migration of mailboxes were running REALLY slowly (3-4 mailboxes a night, as opposed to 50-300 that most orgs see). Many of the blog posts folks read on the Internet place the blame on Microsoft and orgs wait for Microsoft to "fix the performance problem", however we frequently find odd configurations of firewalls and proxies, security settings, and migration server problems to be the culprit. And without proper planning and testing beforehand, many times organizations are sitting in the middle of their "migration weekend" to realize there's a problem, than having tested a flow of dozens of mailboxes beforehand.
- Worked Fine in the Lab: Another similar problem is when orgs setup a test lab and a test Office 365 account and do everything in test and it works fine, so then they do a big cutover weekend only to find problems with the big production cutover. There are a LOT of best practices we've uncovered from these situations, that a lab internet connection many times has less traffic on it than the production Internet connection; or test mailboxes have no mail corruption whereas real mailboxes may have embedded corruption within the old Exchange database; or lab servers don't have layers and layers of security policies and proxies applied to them that the real managed servers in production have on them. Lab testing frequently does not address the experienced results of what will go on in production on the day of the cutover
- Email Archives: It's amazing how many email archiving vendors that orgs have used for years have NO method of getting your emails out of their archives... For years, you've been stuffing emails into archives, creating stubs in Exchange and archiving attachments, moving archives to cloud-based solutions, but now that you want get rid of that archiving solution and just move ALL your email (and archives) to Office 365 (being that Office 365 provides you virtually unlimited archive storage plus extensive eDiscovery, Legal Hold tools), that you find you can't get your archives out of your existing archiving product. And while some orgs have migrated their mailboxes to Office 365 but kept their old archives on-premises with their existing vendor, the cost of these archive vendor solutions and the complexity that archiving is with many of these solutions makes it one of the reasons TO get rid of them and move everything to Office 365! In one case, the archive vendor had no tool to migrate stuff out of their archive, so we had to go directly to the storage system and extract BLOBS of content and rebuild archives, which was extremely successful, but left a bad taste in everyone's mouth when the archive vendor really put the gun to the customer's head saying they have to keep the archives with this vendor forever... (Fortunately, with our workaround, not so...)
- Bad advice -- one organization's prior Office 365 consulting adviser insisted without a doubt that it was required to install an Exchange 2013 server as the hybrid server when they already had a perfectly working redundant load-balanced Exchange 2010 SP3 CAS array. Further, they had them install that hybrid server in a different site from where the servers are normally activated, resulting in a non-redundant hybrid configuration that was suboptimally configured network-wise. Adding insult to injury, the URLs were not properly configured.
So bottomline, Office 365 Migrations are not simple cookie cutter processes that someone can just "wing-it" over a weekend, but to do it right, have someone with deep rooted expertise in Exchange, Office 365, archives, security, DNS, storage, firewalls, proxies, networking, Autodiscover, Active Directory, AD FS, DirSync, PowerShell, client app packaging, pushing out policies to endpoint clients, mobile device management expertise, ActiveSync policies expertise, etc.
Anything short of someone knowing this and a lot more, a migration can come to a halt, many times during the middle of a big migration weekend, and then someone needs to unravel what was done, potentially redo stuff from scratch, and get the process going forward, as it likely should have been done in the first place.
Handful of thoughts here, hopefully this will help you identify things in advance of your migration to Office 365 and be better prepared in the process!!!
