Read an Excerpt
Chapter 3: Migrating to Exchange 5.5Now that you have a solid plan for deploying Exchange Server, it is time to turn your attention to getting the users up and running. If you are like most of the rest of the world, you are probably already running a messaging system of some sort. You are now faced with the challenge of getting your users and messaging data moved over to Exchange Server.
Migration of any sort is never easy, and migrating a messaging system is especially painful because of the complexity of moving from one messaging platform to another. Migrating file and print services is not as complicated because you are only changing the location that the data resides on. However, migrating a messaging system not only moves the data, but it changes the way the user works with that data.
Some of the migration topics discussed in this chapter include:
- Taking a "big picture" look at migration: what is going to be migrated, addressing changes, interoperability, and so on
- Winning the support of your user community
- Getting users involved in a pilot system so you can get accurate and adequate feedback
- Deciding on what functionality and interoperability levels to provide during and after migration
- Getting your users adequately trained to use Exchange and Outlook
- Using Exchange as a messaging hub to connect several different systems
- Addressing interoperability issues if you are going to be handling the migration in phases rather than all at once
- Using migration tools such as the Migration Wizard to convert user's messages from their old system to Exchange
NOTE In Chapter 1, I talked about collecting documentation relating to your legacy mail system. That documentation will be useful when we start talking about migration.
Migration - The Big Picture
Migrating a messaging system is at least as complicated as migrating your operating system. There are many issues to consider, including:
- Selling the system to the executive and operations folks
- Launching a pilot project and getting users involved
- Deciding what to migrate and what to leave in place
- Getting users adequately trained to use the new system
NOTE In this chapter as well as in others, I often refer to the system that you are migrating from as the legacy system. I am not insinuating that new versions of Novell GroupWise, Lotus cc:Mail, Lotus Notes, or other modern mail systems are legacy systems. I apologize ahead of time to my friends in those camps if they are offended. <grin>
Gaining User Support
Before starting the implementation phase of a new Exchange migration, you need the complete support of your management. In a larger organization, you should have full support from top-level management. Implementing a messaging system such as Exchange is a big enough decision that it warrants getting the CEO to understand and approve the project.
Just as important as getting management approval is generating a certain level of excite-ment within your user community. Prior to migrating the first mailbox, your users should understand what is about to happen and what the benefits of the migration actually are. I have worked on too many migrations where I encountered resistance from end users at every step of the project. Migrations do not have to generate animosity and resentment from the user community; this may come as a minor surprise to some IS veterans. Arriving at work to find a mob of angry end users burning you in effigy in the parking lot is not a great way to start a migration.
Exchange@Work: Using Good Marketing Techniques to Win User Support
Company LMN completed their Exchange design, validated their design in the test lab, set up solid operational procedures, agreed upon organization-wide standards, and had a solid migration plan in place. The only problem was that the user commu-nity was not enthusiastic about the migration.
To gain user support, LMN decided to market the next Exchange system just as if they were marketing a new product. They created a logo for the project and hired a technical writer (rather than a system administrator) to create a Web site about Out-look and Exchange. This site also included valuable project information such as:
- New benefits that the users would realize immediately upon moving to Exchange and Outlook. These included Internet mail capabilities, group sched-uling, a company-wide phone/address directory, the ability to read their e-mail from home using a Web browser, and the ability to recover deleted messages; these were all hot buttons with this user community. This list was important to the user community - they needed to see distinct benefits!
- Future capabilities that IS was planning to introduce once everyone had migrated to Exchange and Outlook.
- Implementation and training schedules, including which departments were going to be migrated.
- Internal documentation on how to use Outlook and new features.
- Project contact and help desk information.
- Frequently asked questions and answers.
- Current project status information.
A Service Level Agreement (SLA) detailing expected system availability.
This project's Web site helped generate excitement and anticipation for the coming migration. No longer were the users going to "have to learn something new"; now they were getting new benefits. The SLA was important because it both set expecta-tions of the user community and gave the system administrators a level of service to live up to.
Getting Users Involved in the Pilot Project
Regardless of how much you test in the lab, I promise that a pilot project is going to coax bugs and problems out of the woodwork that you never knew existed. Everyone has their own views on setting up a pilot system, as do I. Since company and environment is unique, I would say to take all my recommendations in this section with a grain of salt. There are, however, three important points to apply to all pilot systems:
- Listen carefully to the feedback from your pilot users - not only what went wrong, but also what went well and what they liked. This feedback should be a written, formatted critique with a place for pilot users to enter their own com-ments. Plan to sit down and talk with as many of these users as possible about their remarks.
- Don't be afraid to make major design changes if you find things that are wrong. It is a pilot system, not the final product.
- Review your pilot project findings with the rest of the IS team as well as with your supporters in the management food chain.
A critical part of any pilot project is getting key individuals involved. So who should be included as part of the pilot project? One of my clients suggested taking volunteers and then rejecting all of those who offer to help. Part of me really likes this idea based on vol-unteers I've worked with in the past. Pilot project volunteers generally have a strong interest in the new system and want their voices heard, and they can often overshadow critical feedback from other pilot users. Still, the enthusiasm generated by volunteers is harder to muster from drafted participants.
Deployment of the pilot system gives you an opportunity to verify your design and look for potential pitfalls. During the early stages of a pilot, you may discover that the entire design needs to be re-thought. Smaller numbers of people participating in a pilot system are much easier to steer in a new direction. This is why I like to include a few people from This project's Web site helped generate excitement and anticipation for the coming migration. No longer were the users going to "have to learn something new"; now they were getting new benefits. The SLA was important because it both set expecta-tions of the user community and gave the system administrators a level of service to live up to....