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.
Sign up for CIO Asia eNewsletters.