Migrating mailboxes while remaining online is a straightforward process. Complications arise when you try to ensure that messages in transit to the mailbox (sitting in an MTA channel queue waiting for delivery) are not lost in the migration process. One solution is to hold messages sent during the migration process in a held state and wait for the messages in the various channel queues to be delivered. However, messages can get stuck in queues because of system problems or because a particular user is over quota. In this case, you must address this situation before migrating the mailboxes.
You can take various measures to reduce the likelihood of lost messages and to verify that messages are not stuck in a channel queue, but at a cost of increased complexity of the procedure.
The order and necessity of steps in the procedure vary depending upon your deployment and whether every message addressed to every mailbox must not be lost. This section describes the theory and concepts behind the steps. It is incumbent on you to understand each step and decide which to take and in which order, given your specific deployment. Following is an overview of the process of moving mailboxes. This process might vary depending upon your deployment.
Block user access to the mailboxes being moved.
Temporarily hold messages addressed to the mailbox being moved.
Verify that messages are not stuck in the channel queues.
Change the user's mailhost attribute to the new mailbox location.
Move the mailboxes to the new location.
Release held mail to be delivered to the new mailbox and enable incoming messages to be delivered to the migrated mailboxes.
Examine the old message store to see if any messages were delivered after the migration.
Unblock user access to mailbox.