Figure 7 illustrates the five phases of the migration process and the associated workflows.
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:
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.
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.
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
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:
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.