Escaping Vendor Lock-in: Life After Microsoft Exchange

Addressing Typical Migration Concerns

Within IT computing, migration projects tend to be the most difficult, as they often encompass heterogeneous deployments. Groupware services are no exception. A few years ago, messaging services were categorized as mission critical, and today this is even more so, as you must account for calendaring and address book services as well.

Sun is perfectly aware of the obstacles presented by migration projects. Sun's migration solution is designed to remove typical migration concerns, as explained in the following sections.

Providing for a Safe Migration

The migration process needs to occur safely and present little if any risk to your data. Sun's migration process provides a proven methodology and toolkit that enable you to prepare everything before running the actual migration. In particular, the toolkit scans all objects in the directory server, scans all mail messages in the concept of a meta store, rebuilds messaging statistics, simulates the new disk and user allocation, and collects data on how long the migration will take-all in a non-intrusive mode. Overall, the migration process includes many best practices that were designed to provide for a successful migration.

Ensuring End User Satisfaction

In the context of a Microsoft Exchange migration, the user experience with Microsoft Outlook must not change. Sun Java System Connector for Outlook works seamlessly with the Outlook client to provide the experience with which end users are familiar. The back-end server migration will be transparent to end users.

Complying with and Enforcing Security Policies

Sun's migration toolkit comes with documentation that can help you understand security on the new target system. This documentation enables project leaders to review the security during the migration and also to understand the access control lists (ACL) remappings for mail folders between non-standard Microsoft Exchange capabilities and the standard IMAP ACL normalized model that is implemented in the Sun solution.

Preventing Transcoding of Data

The migration process prevents transcoding of any data content during the migration. You want this kind of behavior from a migration, in case legal issues arise later. As a company, you might need to be able to present evidence showing that your data was not modified during the migration. The Sun toolkit does not modify your data in any way, except where some Microsoft Exchange messages are not RFC 822 compliant, and thus need to be repaired.

Keeping Migration Cost Low

Sun wants to make it as easy as possible for customers and partners to migrate. Sun also wants to make the service side of the cost as small as possible. Thus, there is no `per user' cost for its migration toolkit.

Keeping Message Storage Requirements the Same

You do not need to increase your storage requirements as a result of the migration. The Sun Java System Messaging Server Message Store uses a single-copy store methodology that is fully functional with migrated messages. For more information, see Appendix A, Appendix.

Keeping User Passwords the Same

With the Sun migration tool, there is no need to discover or “hack” user passwords, change them, or require users to change their passwords after the migration. Additionally, the migration tool itself does not need to know the passwords to accomplish its work.

Note –

Sun estimates that upwards of 50 percent of a company's internal support calls involve user passwords. Forcing users to change passwords as part of a migration strategy would severely impact a company's help desk. This would also have many other potentially harmful side effects, as passwords can be used in other areas, such as for single sign on access and for batch processing.

Ensuring Coexistence

Coexistence is ensured by synchronizing the Microsoft Exchange and the Sun platforms. This means that the Sun toolkit treats the coexistence issues up to a certain point, in particular with the following components:

Making the Migration Simple

Sun's experience with real-world migrations has shown that once you have completed all the necessary upfront planning, analysis, and configuration, a migration does not need to be carried out by the most technical of a company's support personnel. With a minimum of training, your operators should be able to accomplish the actual migration steps. In practice, where you should spend time to smooth the migration is by:

Keeping Migration Time to a Minimum

In general, the Sun migration tool only needs five to ten minutes to migrate a normal user's actual data. The real migration bottlenecks occur in the following order:

  1. Microsoft Exchange is the first bottleneck. In particular, Microsoft Exchange 5.5 on Windows NT 4 has several design issues that slow down the migration.

  2. The second bottleneck can be your network.

  3. The third bottleneck can be the migration machine if it is under-sized.

  4. A real bottleneck is the capability of your help desk and the support team to correctly deploy Sun Java System Connector for Microsoft Outlook on to the user's desktop. This requires:

    • Configuration at the site level for Connector for Microsoft Outlook.

    • Delivery and deployment of the pre-configured Connector for Microsoft Outlook to the user's desktop. Such delivery requires a additional software in place at your organization, such as Microsoft SMS, or tools such as Alterys.

    • Modification of the desktop login sequence to ensure that the Connector for Microsoft Outlook is synchronized for the first time, just after the user migration has occurred on the back end.

Managing Personal Folder (.pst) Files

Personal folder (.pst) files may or may not be an issue for your organization. If the goal is to recentralize end user's .pst files onto the new target system, it might be reasonable to propose the relocation of .pst files on the new platform as part of the migration.

One potential solution is for end users to upload their .pst files (in non-encrypted form) to a shared file system before the migration takes place. Operators performing the migration reload the .pst files in a special place of a slave Microsoft Exchange server and apply the migration tool with a special mode. End users then receive their .pst files in an `archive' folder hierarchy, which is printable and lists folders in a special area of the Messaging Server.

Other alternatives are possible. Consult with your Sun representative for more information.