| | |
Executive Summary
Regardless of reasons for a migration or the migration platforms, the essence of migration projects is to move a group of users, regardless of size, from an environment with which they are familiar, to an environment which is new for most of them. The main goal is usually to accomplish the move as quickly as possible with minimal disruption to users’ normal working routine. Achieving such a goal requires a great deal of expertise and experience.
Unfortunately, the migration process is often simplified and reduced to e-mail, calendar, and directory data migration, which greatly underestimates the complexity of the effort and causes such projects to fail in the eyes of user communities.
Having been in the migration business for many years and involved in a variety of aspects of mail migration, from creating migration products to planning and executing small- and large-scale migrations, Binary Tree has developed the migration approach further described in this document. This approach has been employed as a road map for numerous migration projects and covers a number of areas, which must be addressed to ensure seamless and efficient migration from any legacy messaging environment to your new messaging environment. While each organization’s environment is unique, and while each migration project has its own specific goals, considerations, and issues, using and further refining a common proven approach lays a solid foundation for the eventual successful result of the migration.
Getting Started
Any migration project regardless of size and duration should consist of two major phases, which can be broken into numerous sub-phases:
- Migration Pilot
- Production Migration
Each phase is described below with additional detail.
Migration Pilot
Conducting a migration pilot is one of the keys to the success of the overall migration project. During this phase the migration process is designed, tested, refined, and documented. Additionally, at the completion of this phase, resource and time requirements for the production migration can usually be clearly identified.
The following activities must be performed during the Migration Pilot:
Detailed review of the legacy and the new messaging environments
Depending on whether the new messaging environment has already been established or is being established as part of the migration project, a thorough review of both the legacy and the new environments must be conducted involving individuals who are responsible for design, deployment and administration of each messaging environment and who have experience and expertise with both environments. Such review must cover server and client configurations, usage patterns, network topology, administration, and numerous other areas, which are common to most e-mail environments. Additionally, review must be in-depth enough to uncover certain environment specifics, which are unique to a particular e-mail environment.
The review team should assess the impact of the legacy environment on the migration process and make recommendations for the design and/or enhancement of the new messaging environment based on the migration considerations.
Creation of the new messaging environment
Depending on whether the new environment has already been established or is being established as part of the migration project, the new environment may need to be created or enhanced during the Migration Pilot phase based on the requirements identified during initial review.
Creation of coexistence between the old and new environments
Regardless of the eventual duration of the migration, coexistence between the legacy and the new environments is absolutely essential for an orderly and seamless migration. Depending on the legacy system, there are various vendor or third-party coexistence tools with different levels of functionality, complexity, reliability, and cost. Decision on which coexistence solution to use depends on availability of such solutions, duration of the migration, functionality and usage of a legacy e-mail environment, and a variety of other factors.
Deployment of the migration tools and migration testing in a pilot mode
Binary Tree’s Common Migration Tool (CMT) has been used for mailbox, calendar and directory data migration by thousands of organizations to migrate millions of mailboxes and has been proven to achieve the highest migration success level. Nevertheless, it is important to understand that no single migration product provides 100% migration success for every environment due to differences between the systems and specifics of end-users environments. Therefore, a small, but representative group of users should be selected for pilot migration to further validate functionality of CMT as it applies to the specific organization’s environment and requirements. Should any data migration issues be identified, they can be addressed as part of expectation setting or as product customization.
Selection of Messaging Client deployment and end-user training approach and tools
Selection of deployment and training approach greatly depends on the size of an organization, end-user needs, and availability of internal processes for software deployment and end-user training. A number of alternatives are available for Client installation: from manual Client installation to various generic software deployment packages to customized third-party Client deployment solutions. Similar options exist for end-user training: from basic quick cards and tutorials to computer-based training to Web-based or classroom presentations and to custom individual training. These alternatives must be explored and ones most applicable to a particular environment selected and validated during the pilot before using on a larger scale during the production migration.
Selection of the migration approach
During the migration pilot testing, a production migration approach is normally created taking into account standard migration practices as well as specific requirements encountered in a particular environment. Migration approach may include different migration options for different sets of users. Migration alternatives normally include:
- Server to Server data migration.
- End-User to Server data migration.
- End-User to End-User data migration.
- Full one-time mailbox migration.
- Migration of Server-based legacy data to Server-based Mail Files on the new system.
- Migration of Client-based legacy data to Server-based Mail Files on the new system.
- Migration of Client-based legacy data to Client-based Mail Files on the new system.
- Migration of an entire legacy mailbox at one time.
- Partial incremental mailbox migration:
- Rules-based mailbox migration:
- Migration of different parts of a legacy mailbox at different times.
- Migration of different parts of a legacy mailbox to different Mail Files on the new system.
A number of tangible and intangible factors contribute to making the final migration approach decision and, once made, it may be further validated and altered to meet specific and, often, unique requirements identified throughout the migration project.
Pilot recap – “lessons learned”
Migration pilot serves as a proving ground for the entire migration process. The pilot group evaluates and provides feedback on functionality and performance of the new messaging Infrastructure, end-user experience with a messaging Client, fidelity of data migration as well as the overall move experience and end-user impact. This feedback must be given serious consideration during and at the completion of the pilot when the production migration approach is finalized.
Production Migration
Production Migration is executed using the approach developed during the Migration Pilot. While migration approaches may differ, the list of production migration activities usually stays the same and consists of:
- Deploying the Messaging Client.
- Delivering end-user training on the new messaging system.
- Executing mailbox, calendar and personal directory migration.
- Supporting end-users in the old environment.
- Supporting end-users in the new environment.
- Supporting coexistence between the old and the new environments.
- Addressing migration questions and issues.
- Tracking migration progress.
Two most important factors in the ultimate success of any migration project are well-designed and well-defined migration process and properly allocated and trained project resources. Both must be clearly identified at the completion of the Migration Pilot and prior to Production Migration.
In Conclusion
Mail migration is not easy; however, with proper planning and preparation it can be performed successfully and meets its goal. Organizational commitment and expertise and experience of migration team members are keys to the success of the project. As decisions are made on the time and resources required for various aspects of a mail migration project, they have to take into careful consideration capability and availability of the internal staff, the amount of time and effort required for internal staff to attain desired level of expertise in performing migration activities as well as whether such expertise has a long-range use within the organization.
Migration projects frequently require and greatly benefit from external assistance provided by organizations with substantial migration expertise and experience. Sometimes such assistance is limited to the migration pilot activities only and sometimes it includes supporting or completely staffing entire production migrations. While there is no single “right” answer to the mix of internal and external resources involved in a migration project, one conclusion is obvious: right resources ensure the ultimate project success.
|