Migration and Coexistence Principles and Design

In the context of this document, the words migration and coexistence have precise meanings. Migration refers to the data migration of end users, in an offline or online mode, but can just as well refer to the project itself. Coexistence, which means you are running both Microsoft and Sun Java System platforms together, comes into play for an online migration. In this mode, you need coexistence of your system being migrated and the new system being migrated to. To summarize:

• Offline Migration. The source service is put offline and is no longer accessible by users. During this time (usually not more than one night or one weekend), the data is migrated from the source system to the target system.

• Online Migration. The source service is left online and the data migration occurs with all users active. This implies that the migration will take more than one night or weekend to accomplish, thus, it requires a coexistence model. Such a coexistence model enables the overall system to keep accepting users to be added on one platform or the other, to allow passwords to be modified, to accept mail messages to be delivered either to the source platform or to the target platform (depending on whether the user was migrated or not), to handle the situation when the user is being migrated, and so forth.

Figure 2 illustrates the offline model.

Figure 2 Offline Migration

Figure 2 shows how the source Microsoft Exchange service is put into an offline status. Clients are no longer able to access this service while the migration takes place. When access is restored, it is only to the new Sun Java System Communications Services service.

Figure 3 illustrates the online model.

Figure 3 Online Migration

Figure 3 shows that migration occurs with users active, and in the presence of coexistence between the old and new platforms.

Most customers prefer an online migration model. However, if costs are a concern and if the source systems support a small amount of users with small data sets, you should consider offline migration.

In the online model, the source service is never stopped while end users are being migrated to the new platform, thus no service interruption occurs. For both the Microsoft and Sun Java System platforms to coexist while the migration of the users occurs, a coexistence model is necessary. This coexistence model covers such aspects as user and group directory level synchronization, password synchronization or just re-initialization, and the delivery of mail messages to their correct destination, including routing of the internal Microsoft Exchange 5.5 message flow.

How the SGMT Toolkit Works

When you perform the actual migration, the migration toolkit makes for easy selection of users and dispatching them in the migration technical workflow. The following figure presents a high-level view of how the migration works for the various protocols involved.

Figure 4 Migration Process and Protocols

The toolkit itself performs the following actions:

• Enables you to remap users, mailing lists, and remote users to the Sun Java System Directory Server LDAP.

• Re-initializes the password without the need to know it, “crack” it, substitute it, or ask for the user to change it.

• Sets up coexistence at the user, password, mail, and public folders levels, and also for some aspects of calendar information.

• Enables online migration to take place without loss of mail messages, without the need to stop the full service, and without data storage expansion.

On a per user basis, the toolkit performs the following actions when the actual migration runs:

• Locks the account on source and target platform

• Sets mail coexistence and holds incoming mail

• Scans mail folders, applies remapping rules, and extracts and remaps folder ACLs, including repairing incorrect Microsoft Exchange access control lists

• Migrates mail messages, including repairing incorrectly formatted Microsoft Exchange messages

• Migrates calendar events, tasks, private contacts, notes, and journals

• Unlocks the account on the target platform

More About MAPI to MAPI Migration

Unlike mail, which uses the IMAP protocol, the only way to currently read and migrate calendar, task, contact, notes, and journal data is by using the MAPI standard. The Sun toolkit makes use of two MAPI implementations to accomplish the task of migrating this kind of information.

First, the toolkit uses the MAPI implementation for Microsoft Exchange that transforms any MAPI call into Microsoft Exchange RPC accesses to the Microsoft Exchange server. Second, the toolkit uses a MAPI library to transform the call into the appropriate IMAP, WCAP, WABP, or LDAP call depending on the different Sun Java System server involved.

In principle, to migrate calendar, tasks, contacts, notes, and journal data, a MAPICopy program walks through each object in each folder to:

1. Perform a 'MAPI Copy' of the object from the interface

2. Read the data from Microsoft Exchange

3. Perform a 'MAPI Paste' of the object on the interface

4. Copy the data to the Sun Java System servers with the appropriate protocols

The MAPICopy program works without changing anything in the migrated object because the object remains the same in an homogeneous MAPI context.

Figure 5 illustrates how the MAPICopy program takes objects from the source platform and transfers them to the target platform.

Figure 5 MAPICopy Program

Items the SGMT Toolkit Cannot Migrate

Currently, the toolkit cannot migrate the following:

• Forms. Contact your Sun Partner for help in this area. Usually, this is a good opportunity to understand why you are using forms, and how they can be streamlined. In addition, you might want to consider using Sun Java System Portal Server and new SeeBeyond offerings in place of forms.

• Server rules. Due to folder remappings, it is impossible to correctly recompute server rules in advance of the actions. Normally, this is not a problem, as you can easily recreate the server rules on the target system. This is also a good opportunity to force a review of those rules.