When you are transitioning from a legacy Exchange version to either Exchange 2007 or Exchange 2010 you will come to a stage in the project at which you need to plan for the migration of mailboxes to the new servers.

In small to medium size businesses the considerations are fewer than for larger enterprises, but they do share several in common.  Generally speaking you should plan for the following items.

End user interruption – when a mailbox is moved the end user will be disconnected from it.  Older versions of Outlook do not handle this very well, but even newer versions will need the end user to restart the application to connect to their new mailbox.

This means that it is often best to schedule migrations to occur outside of normal business hours.  Evenings and weekends are very common for this.  If a business operates 24 hours a day using rotating shifts then you can schedule migrations to occur so that a given user is moved when they are not rostered on duty.

Transaction Logging – a mailbox migration means that on the target server (the new server) a whole bunch of new data is being written into the databases.  This creates a very large amount of transaction logging, often much larger than what a normal day’s email traffic would generate.

There are a few ways to manage this.  Moving mailboxes in smaller batches keeps logging to a minimum but means migrations will take longer.  Provisioning large amounts of disk space on the logging volume means bigger batches can be migrated, but after the migration is finished it can mean wasted disk space that is not needed for day to day logging levels.

Usually a middle ground between the above two methods is taken.  Less popular methods include running backups at intervals during the migration window to truncate the logs, or using circular logging which keeps logging to a negligible level but can create serious disaster recovery limitations.

Network Speed – the available network speed between the source and target servers will be a factor in how much data can be pushed across in one session.  Target servers are almost certainly going to be gigabit connected, but older source servers might still be 100 megabit.

In other cases where server consolidation is being done, the migrations may be occurring over low bandwidth WAN links of just 1 or 2 megabit.  This will certainly mean smaller batches are used during the migration.

Disk Speed – even with high speed networks the disk speeds on the source and target servers can impact migration speeds.  The source server will be performing a lot of read operations, and the target server a lot of write operations.  If either of them has a disk subsystem or RAID type that is not optimal for those conditions then migrations may be slowed down.

Backup Windows – since mailbox migrations often occur during the evening or weekend this means they are occurring during the normal backup window.  The implications here are that if the backup of the target server is run before the migrations are finished, some mailboxes that are still in the process of being moved are effectively missed from that night’s backup.  This exposes them to higher risk of data loss if the server experiences a problem before the next backup window.

In all of the above cases the risks and impacts should be understood and planned for.  With the right planning and testing each of these issues can be analysed for their actual impact and the resulting risks can then be mitigated with procedural solutions.