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.