Organizing the Migration Project

This section provides the migration problem statement and describes how you need a good methodology to approach the problem. It also describes the five phases of migration, from a situation where no Sun products are in place, to a situation where the migration occurred and the old system is decommissioned.

Migration Problem Statement

A messaging migration project involves many activities, spanning management, technical, and methodological issues. Figure 6 illustrates the high-level view and overall direction of your migration project.

Figure 6 Initial State of the Migration Project

Understanding the importance of the migration problem, Sun has developed specific steps (phases) for a migration project to drive a platform from a certain source groupware to Sun Java System Communications Services. This entails understanding:

• Your business, its Service Level Agreements (SLAs), policies (security, archiving, and so on), your organization, and its processes.

• The actual platform running the source groupware system. In particular:

  • Hosting data, general architecture, flows, and so on.

  • User data provisioning, data quality, double provisioning, synchronization, and so on.

  • Disk space usage and other statistics. Specific attention should be paid to the storage expansion rate, which is resolved in the second phase of the project.

The migration project relies on information extraction tools which support some of the steps:

• SGMT provides tools to identify LDAP data issues and to remap user data in a flexible manner. This enables specification and customization of the synchronization between the source and target LDAP services.

  For example, some user login strings can contain characters that are forbidden on the target system. Additionally, because of consolidations in the Directory Information Tree (DIT) into a more global flat tree, duplicate IDs can occur. SGMT detects these problems before and not during the migration such that you can contact users and take corrective actions before migrating.

• SGMT provides tools to compute statistics on users, to simulate their reallocation on the future system, and to evaluate partitions. This information supports ordering or specifying storage requirements as well as refinement of the architecture.

• SGMT then performs the actual migration of the data and provides a migration user status, which allows other systems or clients to take appropriate actions. For instance, the user desktop login scripts can decide to launch Sun Java System Connector for Outlook for each user after—and only after—the user is migrated.

Migration Phases

Figure 7 illustrates the five phases of the migration process and the associated workflows.

Figure 7 Simplified SGMT Workflow

Workshop Phase (Validate Architecture and Methods)

Prior to this phase, you receive a questionnaire designed to collect information on different technical and non-technical aspects of your organization. After you answer this questionnaire, the workshop phase starts. A workshop is a two-day engagement where two Sun architects instantiate the migration project. The two days are broken into four half-day sessions as follows:

• Session 1: Review of the questionnaire and getting to know the customer.

• Session 2: Review all critical problems and show how Sun resolves them.

• Session 3: Sun articulates the vision and general architecture.

• Session 4: Sun proposes the project format with milestones and dates.

Preferably, the following members of your organization should attend this workshop:

• Project sponsor

• Groupware architect

• One person from the production team (hosting, network, SAN, disaster recovery, data center, geographic dispersion, and so on)

• One person from the security team

• One user representative (for example, from the Help Desk)

• One person from the desktop team

Sun and/or its partners align the two architects, one engagement manager, and one project manager.

After this workshop Sun and/or its partners have all the elements necessary to make a proposal, and a report is written.

Specifications Phase (Design and Plan)

During the second phase, the SGMT tool creates reports on which you base the architecture of the target platforms, as well as migration modalities. As part of this phase, an integration platform is built to support deployment of SGMT for a first-pass analysis and profiling.

Next comes the qualification of your data. Potentially the most demanding task in this part is the analysis of the LDAP data quality. Indeed, all data must comply with the toolkit's requirements (based on RFCs). This task integrates as well the synchronization processes between the source platform and the target Sun platform.

Do not underestimate the effort required for writing these “mapping functions.”

To have an idea of the performance of the source system, statistics are extracted through the IMAP interfaces of the source platform. This process detects as well possible anomalies on the source system, including:

• Mailboxes that do not have uids, uids that are not unique, or invalid characters that have been used

• Folders that were created without a type

• Mail messages that were corrupted on Microsoft Exchange that cannot be read with Outlook

• Folder names that contain a slash (/)

• Calendar items that contain invalid data, duplicate uids, or wrong time zones

• Overly “large” mail messages

These anomalies with source data present key risk factors that must be understood for the migration to be successful.

Once you have collected such data, you can then:

• Specify the allocation models for users on the message stores

• Specify and size partitions

• Simulate disk space allocation before the actual migration, taking into account or not the relinker functionality in the Message Store (to avoid migration storage expansion)

Once all these tasks are completed, you are then able to:

• Customize the toolkit to your particular project's needs

• Test the customized toolkit

• Drill down into user profile data

• Drill down into user messaging data

Finishing the specification of the overall platform involves performing LDAP provisioning, user allocations, disk space requirements, and so on.

Build Phase (Configure)

During the third phase, you reconfigure SGMT again, this time to perform the migration to the new platform instead of the analysis, which is a read-only operation on the source Microsoft Exchange platform. In this way, the new target platform is built. At this stage the most critical activity is to enable the synchronization of the source LDAP platform with the target LDAP platform. Once you validate this step, users and mailing lists are synchronized between source and target. On the target platform, “shadow” users are ready with the correct attributes for their respective real users' migration.

During the third phase, you construct components that drive some of the acceptance testing. For example, you need to:

• Set up a test LDAP server, on which you:

  • Add the SGMT schema, password plugin, indexes, and so forth

  • Pass the dirmapping on the current source LDAP server

  • Find and resolve LDAP errors

  • Implement mapping functions and test

• Build a meta store of the source system, and process archival data that exists perhaps for legal or business reasons but that can be reprocessed afterwards, with:

  • A 'per message' md5, size, IMAP uid of mail messages for all users and folders

  • Reporting that enables you to understand users mail usage profiles

  • User allocation preparation and simulation until satisfying rule is found

Migration Phase (Deploy)

The fourth phase enables the actual migration of user profiles and data. In this phase, the following actions occur:

• You have defined how quickly you want your migration to take place.

• Your help desk has been trained and is ready to start answering user questions.

• You have deployed Connector for Microsoft Outlook, and it is ready to launch when the right attribute of the user in the LDAP is set to 'migrated.'

• The migration itself can take place.

• For each migration pass, the following takes place:

  • Select accounts by means of SGMT.

  • Start the migration Dispatcher:

    • The Dispatcher “locks” all selected accounts on both platforms.

    • Mail messages, calendars, tasks and contacts are migrated.

    • Accounts are “unlocked.”

Epilog Phase (Close Migration)

The fifth and final phase involves resolving any problems after the migration has been completed. SGMT is still necessary until the source platform is fully decommissioned, for synchronization purposes. However, as soon as the source platform is completely removed from the architecture, SGMT can be uninstalled, and the migration hardware can be re-purposed. You might need to attend to other, overlooked tasks as well, such as removing DNS entries, decommissioning machines, and so forth.