20.15.1 Migrating User Mailboxes to Another Messaging Server While Online

You can use this procedure to migrate the message store from an older version of Messaging Server to a newer version or to move mailboxes from one Sun Messaging Server message store to another. This procedure should work for iPlanet Messaging Server 5.0 and later. It cannot be used to move messages from earlier versions of Messaging Server or a non-Sun Microsystems message store.

The advantages of moving mailboxes using this procedure are as follows:

• System administrators move the mailboxes from the old source system to the new destination system without users involvement.

• This process is faster than any of the other processes.

• Re-linking is not required if you are moving an entire partition.

• Both Messaging Server systems remain active and online.

• You can migrate all the mailboxes on a messages store or a subset of those messages. This procedure allows for incremental migrations.

The disadvantages of moving mailboxes using this procedure are as follows:

• This method does not work with non-Sun messaging servers.

• The users being migrated will not have access to their mailboxes until the migration of their own mailbox is complete.

• This method can be complex and time consuming.

20.15.1.1 Incremental Mailbox Migration

Incremental migration provides numerous advantages for safely and effectively moving your message store to a different system or upgrading to a new system, incremental migration allows you to build a new back-end message store system alongside the old back-end message store. You can then test the new system, migrate a few friendly users, then test the new system again. Once you are comfortable with the new system and configuration, and you are comfortable with the migration procedure, you can start migrating real commercial users. These users can be split into discrete backup groups so that during migration, only members of this group are offline, and only for a short time.

Another advantage of on-line incremental migration is that you do not have to plan for a system-wide back out in case your upgrade fails. A back out is a procedure for reverting changes you have made to a system to return the system to the original working state. When doing a migration, you have to plan for failure, which means that for every step in the migration requires a plan to return your system back to its previous operational state.

The problem with offline migrations is that you can't be sure your migration is successful until you've completed all the migration steps and switched the service back on. If the system doesn't work and cannot be quickly fixed, you'll need a back out procedure for all the steps performed. This can be stressful and take some time, during which your users will remain offline.

With an on-line incremental migration you perform the following basic steps:

1. Build the new system alongside the old one so that both can operate independently.

2. Configure the old system for the coexistence with the new.

3. Migrate a group of friendly users and test the new system and its coexistence with the old system.

4. Divide the users on the old system into groups and migrate group by group to the new one as desired.

5. Disassemble the old system.

Because both systems will co-exist, you will have time to test and get comfortable with the new system before migrating to it. If you do have to perform a back out procedure--which should be very unlikely--you only have to plan for steps 2 and 4. Step 2 is easy to revert since you don't ever touch user's data. In step 4, the back out is to revert the user's state back to active and their mailhost attribute back to the old host. No system-wide back out is required.

20.15.1.2 On-line Migration Overview

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.

1. Block user access to the mailboxes being moved.

2. Temporarily hold messages addressed to the mailbox being moved.

3. Verify that messages are not stuck in the channel queues.

4. Change the user's mailhost attribute to the new mailbox location.

5. Move the mailboxes to the new location.

6. Release held mail to be delivered to the new mailbox and enable incoming messages to be delivered to the migrated mailboxes.

7. Examine the old message store to see if any messages were delivered after the migration.

8. Unblock user access to mailbox.