by Dean Sesko, Systems Architect at Netarx and Microsoft Exchange Certified Master
Binary Tree would like to welcome Dean Sesko as our guest blogger. Dean is a Systems Architect at Netarx where he focuses on designing and implementing large-scale messaging environments using Microsoft messaging technologies. Dean has several certifications from both Microsoft and VMware and has proven work experience with various enterprise customers.
When he’s not working, Dean loves to brew beer and integrate technology into that process. He’s even written his own beer brewing software application to track the what, how, and when of each step in the beer brewing process.
Check out Dean’s blog ExchangeBytes where he discusses Microsoft Exchange and related technologies.
Having performed hundreds of Exchange email migrations over the past 16 years, I can say without a doubt that managing mailbox moves is the biggest headache of the entire migration/upgrade process. I’ve worked with Microsoft Exchange since version 5.0, and I can say that the process is getting better with each version. Technically, moving mailboxes is quite simple - a few simple clicks in the Exchange Management Console or the execution of a crafty Exchange PowerShell command and you are off and running. However, from a business perspective, there was never an easy way to manage the process. It requires loads of manual intervention for monitoring, tracking and troubleshooting. 
Since mailbox migrations reach so far into an organization, touching not only the end users’ mail client, but also business critical mail-enabled applications, tracking and scheduling downtime is crucial to the success of a migration. The process of informing each user when their mailbox will be migrated and handling exceptions to the schedule requires significant effort. The necessary evils of gathering this data and managing user communications helps keep projects on time and on budget. Unfortunately, this also consumes precious resources that could be better spent elsewhere on the project. Further adding to the mailbox move headache is the stress and strain on staff due to these activities typically being done after hours and on weekends. However, in a 24/7-production facility, there are limited time slices when mailboxes can be moved, thus creating an even bigger logistical nightmare causing migration teams to work around the clock.
In the past I’ve used a series of Excel spreadsheets and PowerShell scripts to lessen the time spent managing this process. For example, I would export data into a CSV file from Get-Mailbox, Get-MailboxStatistics, Get-MoveRequest, and Get-MoveRequestStatistics to use as a foundation for my reports. I would take this data and make it look readable to the non-technology inclined individual by adding graphs and tables to try and articulate where in the project we were and how much further we would have to go. This laborious process was usually done repetitively throughout the night as mailboxes were moved. It goes without saying that this process requires strict monitoring of the mailbox moves to avoid unexpected failures in the process. Nothing is worse than setting up a bunch of migrations to run before you go to bed only to wake and find an error happened in the middle of the night and a majority of the mailbox moves were stalled.
Thankfully, I found a cure for my migration headaches ...