Escaping Vendor Lock-in: Life After Microsoft Exchange

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

This diagram shows the direction of your 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:

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

Migration Phases

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

Figure 7 Simplified SGMT Workflow

This diagram shows the five phases of the migration process and
the associated workflows.

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:

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

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.

Tip –

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:

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:

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

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:

Migration Phase (Deploy)

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

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.