Don’t Move Your Mailbox Data TWICE!!!

The blog post I wrote a couple of weeks ago, about the lack of a ratings system for specialized software tools on the market, included a specific Latin phrase, “Caveat Emptor”, or “Let the buyer beware”. Well, since I wrote that blog, I have been reminded of just how relevant that saying is in the IT industry.

Over the past three weeks, I have interviewed a handful of different companies that have gone through a cross-forest email migration project in the past couple of years.  And believe it or not, they had to move their mailbox data twice. 

Yep, you read that right; they were forced to migrate huge amounts of mail and calendar data TWICE.
 

Because the Outlook email client from Microsoft provides a very powerful capability to use a local, synchronized store of all your mail and calendaring data, you need to be very wary about having to rebuild that local store. Having a local copy of your Outlook email helps with network performance because it provides you the read/write capabilities directly to your computer and the synchronization for new mail and outbound mail is done seamlessly in the background when you are connected to your Exchange server.  This is a must have if you go mobile with your laptop. It’s called “Cached Exchange Mode” which creates a local copy for your email called an OST file, and the large majority of corporate customers use this configuration.  
 
But if you migrate your mail users to a new AD forest, which happens quite often (merger, acquisition, divestiture, hosted cloud, managed cloud, etc), you might just have to rebuild these local OST files. In essence, you would move your mailbox data TWICE. Once to the new Exchange servers in the target AD forest, and then when the users log into their mail for the first time you will also force them to move ALL their mailbox data down to their computers again to rebuild that local OST file. This puts a huge amount of traffic on the network during business hours and quite a bit of stress on the Exchange servers if there are 100’s or 1,000’s of users doing this at the same time, like on a Monday morning. So why would you do this?Mail Storm
 
A recent analysis performed by Windows IT Pro included this as a major comparison item between the legacy Quest Migration Manager for Exchange tool and the new E2E Complete software product from Binary Tree. What they found was that consulting companies (system integrators) that used the legacy Quest tool were forcing their customers to move their mailbox data twice because of the necessity to rebuild their local OST files after a migration.  
 
The customers I interviewed were totally surprised when this issue came to light during pilot testing. They found that they had to update their entire project plan because they could not move that many users each night, or weekend, due to the crushing network traffic the morning after the migration events. Effectively, this slowed down their migration plan and the entire project took almost twice as long as they originally estimated. And for them, this was a definite example of “Time is Money” because the elongated project made them pay for more professional service hours from the systems integrator they had contracted with to perform the migration with the legacy Quest tool.  They would not have had this issue if they had used the E2E Complete software from Binary Tree as it retains the original OST files for end users.
 
For more information comparing the legacy Quest tool versus Binary Tree’s E2E Complete, you should check out the Windows IT Pro white paper “Binary Tree E2E Complete vs. Quest Migration Manager for Exchange” and consider attending theWindows IT Pro webinar “What to Look For In Exchange Migration Tools” on February 28th.
 
So the moral of the story is that you should really do your homework when you pick a specialized software tool to help you with a specific need, such as an email migration project. It might just save you a lot of headaches in the long run, and save you a bunch of money too.