To migrate from Microsoft Exchange 5.5 (and other groupware services) to the Sun Java System Communications Services platform, Sun provides you with the Sun Groupware Migration Toolkit and Methodology (SGMT). SGMT is not limited to the 5.5 version of Microsoft Exchange, nor to Exchange itself. In particular, SGMT currently covers MS Exchange 2000 and 2003, and Critical Path migration. To keep this document from becoming overly long, the discussion has been restricted to the Microsoft Exchange 5.5 use case.
Sun's methodology allows, by design, a safe migration project with no surprises, as long as it is fully developed. It covers step by step all solution aspects, not just the data migration per se. The methodology includes simulations and analysis before you attempt to run the actual migration. The methodology also enables you to implement several scenarios, in particular the online migration model with coexistence.
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 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 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.
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.
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
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:
Perform a 'MAPI Copy' of the object from the interface
Read the data from Microsoft Exchange
Perform a 'MAPI Paste' of the object on the interface
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.
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.
There are no particular restrictions for migration. However, experience has shown that not all formats are appropriate to every situation. There are many aspects of a migration to consider that can influence whether to use an offline or online model, whether to leverage Sun partners, and so on. Consider the following factors when determining your migration:
Number of users. Small companies with fewer than 100 users and simple requirements might want to use an offline migration model.
Existing Service Level Agreements. Companies that have mission critical SLAs can only use an online migration model, ensuring no end-user service interruption.
Developing New Service Level Agreements. Companies might want to take the opportunity to revisit their mission-critical service under an SLA. You might even want to outsource support to a business-to-business messaging hosting platform from the Sun customer network.
Identity Management. Companies that have or want a more mature provisioning model can use this opportunity to revisit their identity workflow. Consider starting a Sun Java System Identity Manager project prior to the migration project. For more information, see: http://www.sun.com/software/products/communications/partner_library/index.xml
Third-party Applications. Companies that use third-party or in-house applications on Microsoft Exchange should consider rehosting these applications with Sun Java System Portal Server and Sun Java Integration Suite offerings. You need to review specific applications, such as voice-based systems, unified messaging, integration with fax, and so forth, on a case-by-case basis.
Distributed Topology. Companies with most or all system components and messaging processes distributed across multiple sites will want to consolidate. This process requires pre-project work. In particular, data centers need to consider networking, security, and even disaster recovery.
Unsolicited Bulk Email (UBE). You might want to take this opportunity to include revisiting your anti-virus and anti-spam plan. Sun Java System Messaging Server offers many anti-virus and anti-spam tools, including mailbox filtering, address verification, relay blocking, and integration with various third-party anti-virus and anti-spam products.
Archiving. As part of a migration, companies might want to add some archival features (in addition to your backup plan) to their messaging system. You might also want to introduce compliance and content management systems. Sun currently partners with AXS-One on compliance systems. For more information, see: http://solutions.sun.com/partner/pd/PartnerDetail.jsp?vendor_id=1019722
Choosing a new desktop. Companies concerned with support costs, TCO, and so forth, might want to take this opportunity to consider removing the Microsoft Windows desktop itself, and use an alternative such as Sun Java Desktop System.
There is no single answer to cover all of these situations. As such, Sun and its partners take the time upfront during a two-day workshop to assess the particulars of your organization to arrive at the correct way to handle your migration. See Workshop Phase (Validate Architecture and Methods) for more information.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Directory. Can occur as one-way or two-way synchronization for:
Mailboxes
Distribution lists and groups
Custom recipients ('LDAP entries' in Microsoft Exchange that point to external mail address that are not part of the Global Address List (GAL))
You can also perform a bulk synchronization of the directory level. You must perform customizations at this level through remapping rules. In addition, the Sun migration tool offers documented APIs to flexibly remap anything that you like to the target Sun LDAP server.
Passwords. The Sun toolkit does not need to change the user password. The toolkit operates “cleanly” on passwords, with no need for users to substitute a new one.
Mail coexistence. The Messaging Server MTA is able to “hook onto” the SMTP flow and copy/forward model to ensure that the Microsoft Exchange mail messages are routed to the new platform.
Calendar free/busy lookups. Coexistence enables users to see the free and busy status of their colleagues, however, only migrated users can view the status of non-migrated users. Non-migrated users are not able to view the free/busy status of migrated users. Nevertheless, experience has shown that the fact that it works for migrated users actually encourages non-migrated users to get migrated.
Public folders. Microsoft Exchange public folders are synchronized with Sun shared folders to ensure that migrated users within a community are sharing the same data between the two platforms.
Calendar synchronization. Unfortunately, performing a full calendar synchronization is almost unrealistic, as there are too many conflicting requirements. For example, not only must you add or delete calendar entries, but you need to inspect each and every property, and there is no notion of “who wins” the reconciliation.
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:
Preparing email to end users and an intranet page explaining more details on the migration
Sending notifications to end users when their migration will occur
Validating the migration, once it is completed, and analyzing post-mortem issues, if any (usually this just involves reassuring users that their data is there)
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:
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.
The second bottleneck can be your network.
The third bottleneck can be the migration machine if it is under-sized.
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.
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.