A Winning Strategy for Messaging Migration: Step-by-Step Advice for Avoiding Migration Disasters

Explore many of the common pitfalls associated with messaging migrations and arm yourself with step-by-step guidelines for ensuring a seamless and productive process.

• 10/01/2000

With the availability of free migration tools from e-mail vendors, messaging migration can at first glance appear to be a "slam dunk" process, having little or no impact on day-to-day business. Unfortunately, for enterprises (those comprising a few thousand users to more than a hundred thousand users), the so-called "free" migration tools can end up costing an enterprise hundreds and thousands of unexpected dollars and just as many lost man hours.

Why is messaging migration such an ominous task? How can you prepare for it so that you come out a champion and not a migration casualty? This article will explain to you many of the common pitfalls associated with messaging migrations and will arm you with step-by-step guidelines for ensuring a seamless and productive process.

Many enterprises choose to migrate to new messaging systems in order to benefit from new features and capabilities, or because their older systems have become difficult to maintain or are not Year 2000-compliant.

The average enterprise supports six or more different e-mail systems. Using gateways, message switches, and directory synchronization technologies, enterprises can successfully integrate disparate systems. However, the challenge presented by the coexistence of various e-mail systems is that each different environment can have its own proprietary e-mail system and its own method of addressing and storing messages. This can make enterprise messaging quite difficult to manage, as well as costly. Moreover, enterprises oftentimes discover that a complex environment of many different messaging systems results in lost messages, long delivery times, complex addressing, corrupted e-mail attachments and the inability to communicate with Internet mail users.

By migrating to a simplified environment of consolidated messaging systems, enterprises can save significant time and costs that would otherwise be spent on supporting dissimilar systems.

All too often enterprises are led to believe that "free" migration tools can fulfill the function of a complete messaging migration solution. The problem with these tools is that they do not address how the enterprise will maintain the flow of information and sustain day-to-day business, nor do they consider how to train and prepare users for the migration process. In order for the benefits of messaging migration to be realized and costly mistakes avoided, an enterprise needs a well-thought out plan, powerful technologies for e-mail gateway and directory services, directory synchronization, Internet mail routing and message store migration, and possibly outside consulting services.

Before delving into how best to prepare for a messaging migration, here are some of the most common mistakes and strategies for avoiding them.

Not Understanding the True Impact of E-mail. E-mail is no longer just an alternative form of communication. For most businesses today, e-mail, or messaging, is essential, just like the company’s phone system. According to a recent Pitney-Bowes study, the average office worker sends and receives over 200 messages per day. It’s likely that a great number of these messages concern important meetings, projects, and other information that’s important to the business.

By considering the following questions for your enterprise, you can determine how high the stakes could be for your migration project.

• What will it cost if e-mail directories are corrupted and e-mail is down for hours or days due to a migration?
• What happens in the middle of your messaging migration project if the gateways can’t handle the traffic load and e-mail is terminally slow?
• What’s the impact if stored messages are lost? How about personal address books?
• What’s the benefit of completing the migration sooner than planned?

Underestimating the Politics Involved. Politics are an inevitable component of nearly every enterprise messaging migration project. Since each business unit typically has its own unique requirements and preferences, they will likely have their own ideas for how best to implement the migration. Since most enterprises will have a multitude of divisions, it can be extremely difficult to gain consensus. In fact, coming up with a plan that is agreed upon by all key decision-makers can take months. One way to estimate how long it could take your enterprise to agree on a plan is to review your company’s previous enterprisewide IT projects for how long the consensus stage has usually taken.

Because of the politics involved, a project sponsor, such as the company CEO, can be very helpful for gaining consensus among different groups. At the least, the CEO needs to provide leadership and support for the project. Business unit managers also can be key members of the leadership team and act as project sponsors. It’s also common to see companies rely on a "grass-root" committee that comprises members of different business units. Whatever the approach, it’s critical to determine how you will obtain consensus and who the key decision-makers will be.

Not Getting the Necessary Outside Help. In order to complete the migration project on time and on budget, outside consultants are oftentimes necessary. First, consultants bring the benefit of having been involved in numerous other enterprise messaging migration projects. Second, the extra assistance may also allow you to stay focused on other projects and not be overly burdened by the migration. Furthermore, being an objective participant, a consultant may help to gain consensus among the different groups.

Not Having a Plan in Place. A comprehensive migration plan is essential for large organizations since it will show you in advance what needs to be done and how to meet the project deadlines and budget requirements. Consultants usually offer migration planning as one of their services and will custom-fit the plan to your organization.

Early on you will want to decide who is going to perform the messaging migration for your enterprise. Will it be internal IT staff, your migration consultant, or another third party? The key considerations are whether you have the resources and whether you want them devoted to messaging migration. From the initial planning stages to the completion of the migration, the time spent on the project can range from three months to over three years, depending on the size of the enterprise, the number of different e-mail servers, and the time it takes to form consensus for the project.

Define the Current Environment. To help determine if you need outside help, assess how complex your migration project is by creating a network diagram that shows how the various e-mail systems are currently connected in the enterprise.

In addition to showing the names and vendors of existing messaging systems, the diagram could also display the different gateway or message switch products, as well as the geographic locations and the number of users on each e-mail system. Other details that you might want to include are the Internet address standards, message traffic volume (both internally and externally), typical message size and message store size, the network bandwidth between systems and locations, and names and contact information for the different IS personnel responsible for these systems.

Choose the destination system. A major component of the migration process is selecting the new destination system if the enterprise is wishing to migrate to a new environment. Among some of the factors to consider when selecting a new messaging system are 1) the company’s preferred vendor; 2) features and capabilities; and 3) support for and integration with your existing systems. This stage of the migration process can quickly become a holy war if not managed properly.

Determine New System Requirements. Once you have decided on the destination system, the next step is to determine the system requirements. For instance, what will be the standard messaging server and desktop client configurations? How many messaging servers will be required, where will you need to put them and what will be the network bandwidth requirements between servers? Also, you’ll want to consider the user training needs.

Determine Migration Policies. Two philosophical approaches to messaging migration are the "brute-force" method and the "process" method. The brute force method is utilized by migration tools that are usually provided free of charge by e-mail vendors. These tools require that everyone move at the same time, and that end users have the software installed on their desktops, where each end users is responsible for moving their own message store to the new system. Usually, stored messages and personal address books can not be moved to the new system. Furthermore, the support time and costs associated with supporting thousands of end users running their own migration software forsake the benefit of these tools being free. For a large enterprise, simply not having the ability to centrally manage the process is a good enough reason for choosing against this approach.

In comparison, the process method relies on a comprehensive migration solution that includes careful planning and a systematic execution that is centrally managed. Divisions in the enterprise are migrated in stages and message stores are maintained, as well as other important information. A robust set of migration technologies translate formats and addresses between the old and new systems, and preserve and move e-mail folder structures, personal address books and distribution lists. Other benefits can include on-site services for assisting with communicating the plan to users and preparing them for the migration. While this approach is not free, in most cases, it is much more cost effective since the enterprise will not incur the unexpected and oftentimes more detrimental costs associated with disruptions to day-to-day business and internal and external communications.

Some of the other policies that you will need to define include: 1) What will be migrated and preserved? What if any restrictions will you have on dates, attachment sizes, read or unread messages, and international characters? 2) Should users be able to reply to stored messages from the old system? How will you handle archives and laptops? And, 3) will you keep the same Internet mail addresses or will you have a new standard? Other areas to consider are personal address books, distribution lists, bulletin boards, personal calendars and mail-enabled applications.

Select the Migration Infrastructure. The different technologies used in a complete migration solution need to manage e-mail gateway services, enterprise directory services (including directory synchronization), Internet mail routing and message store migration. An e-mail switch is used when there are more than two different e-mail systems. Sometimes six to 10 message switches are required to handle peak loads when half the enterprise is on the old e-mail system and half are on the new system. However, the more scalable the message switch, the fewer you will need.

When selecting a complete migration solution, it’s important to choose technology that is tightly integrated with your message switch and directory synchronization infrastructure, and that works directly with the message routing process. This will enable the proper translation of messages and will allow users to reply to stored messages so that you can maintain the flow of e-mail as users are moved to the new messaging system. Other essential capabilities include: the ability to update e-mail routing as users migrate, ease-of-use with selecting groups of users and migrating various e-mail components, as well as the automatic creation of accounts on the new system and updates to the enterprise directory.

Decide on the Migration Timing. A key part of the migration planning is determining when users will be migrated. As mentioned earlier, the "process" approach to migrations advocates moving users in stages so that the project is more manageable, and so that if you do come across a problem, you will have only impacted one group, not the entire enterprise. Also, by moving users one business unit at a time, you will be able to address special needs, such as not migrating the finance department just before reporting fiscal year-end earnings.

For large numbers of message stores, it is usually easiest to execute the migration in a two-step process. First, the majority of stored messages are moved two to three weeks ahead of time, and then the remainder are moved the weekend before users are cutover to the new system.

The migration plan should show date ranges by business units. Each business will have specific dates for installing new hardware and software, training users, migrating message stores, and moving to the new system. A timeline is useful for helping you to track the project as well as for communicating with users. The timeline should show all steps and requirements involved in the migration and the required resources.

Prepare an Emergency Plan. This section of your migration plan will help you to be prepared should things go wrong, such as e-mail directories becoming corrupted. It’s important to think through possible problems and to develop contingency plans before migrating any users.

In order for the migration project to receive support from the enterprise, it is important to communicate to all involved why the enterprise is migrating, what system (s) they are moving to and when the migration will occur. This information can be communicated via an e-mail or interoffice memos, and you may even want to personalize your message by performing an e-mail merge. For general information, a brochure or one-page flyer describing the project and the benefits can help with gaining consensus throughout the enterprise. Many organizations also develop a migration web site accessible on their Intranet to house frequently asked questions, training schedules and other useful information.

Two to three weeks prior to the migration, you will then need to distribute memos or e-mails to users letting them know specific details relating to the project. Users will need to know the migration schedule for their particular business unit, their new account names, addresses and passwords, what will happen to their stored e-mail, folders and personal address books, and who to contact with questions or issues.

Before moving any users, a migration pilot is recommended for uncovering potential problems — before it is too late. To create the pilot, set up a test lab that includes your primary e-mail systems, your messaging integration and migration technology, and your destination e-mail system. As you go through all of the steps of your migration plan, document your results and make changes where necessary.

After you have executed the pilot, it is then time to migrate the first business unit on the schedule. At this point you may want to explain again to users the process and how they will be impacted. As you migrate the first group, also document the results, as you did with the pilot, and adjust your migration plan as you go. You will continue repeating the migration process on a business unit basis. Once complete, you can shut down and de-install your old e-mail systems and wait for the next migration opportunity.

Almost every enterprise, whether from mergers and acquisitions, the year 2000, or in order to benefit from new e-mail capabilities, will at some point undergo a messaging migration project. Unfortunately, many of these enterprises will underestimate the time and technology needed to successfully move users in a way that does not negatively impact the business. However, by knowing what can go wrong and how to plan for it, messaging migration projects can produce rewarding results for the enterprise. With consensus and leadership for the project, a process method of migration with detailed planning, and tightly integrated messaging migration and directory synchronization technology, an enterprise can deploy new e-mail systems on time and within budget.