If your organization is considering moving to Microsoft Exchange 2000 from either Exchange 5.5 or other messaging systems such as Lotus Domino or ccMail or Novell’s GroupWise, there are obviously many issues to contend with, many key decisions that need to be made, and a significant amount of time, effort, and money to be invested in the process.

To ensure the success of your Exchange 2000 migration, you’ll need to devise a thorough plan for the project. In this article, I’ll tell you some important factors to consider when shaping your migration requirements, and I’ll help you get your staff ready to begin the project work.
To be sure that Exchange 2000 is the product for you, check out TechRepublic’s Exchange 2000 decision-making flowchart. To download the flowchart, click here.
Determine the desired end-state
Begin planning for the migration by creating a clear goal or vision of what the final result should look like for your organization. That vision will help determine what features of Exchange you will utilize, what service level(s) you can afford to provide, how many locations will be involved, how many clients will be affected, and when the final product will be in place. If you don’t have a clear vision of where you want to be at the end of the process, it will make planning very difficult.

Some questions you will need to answer to help build that mental image of the end-state include:

  • How will clients access their mailboxes? Utilizing Web-based access via Outlook Web Access (OWA) has quite different desktop-support implications than the full client-server version of Outlook. If you are planning to use Outlook, you’re well advised to plan for at least Outlook 2000, and for that matter, Office 2000.
  • How many locations will be involved? Trying to run Exchange from a single site may or may not be technically feasible. Regardless, the number of locations will definitely play a factor in determining how to plan your migration.
  • Will there be PDA connectivity? Connecting Palms or Pocket PC devices will again impact the desktop and the clients themselves. Will this functionality extend to wireless connectivity?
  • What availability will be provided? If you are planning on offering the “five 9s” of availability, you will need to prepare yourself for some high-availability services, such as Windows clustering. This will have a significant impact on hardware costs and will raise the level of complexity and, ultimately, the skill level required to maintain such systems.
  • What additional services will be offered besides the core messaging? Will conferencing be deployed? What, if any, integration will there be with LAN-based faxing? Is unified messaging (i.e., a single mailbox for voice and text messages) in your plans?

Assuming that you’ve answered these questions sufficiently and now have your desired end-state in mind, let’s now outline the key steps required to get your staff ready for the migration.

Gather adequate personnel resources
Personnel resources will make or break your Exchange migration. But before you rush off and put your staff in training, keep in mind what roles will be required during and after the project. Here are some of the key positions to consider during the project planning and execution phases:

  • Project manager
  • Technical architect
  • Team lead: Servers
  • Team lead: Desktops
  • Team lead: Training and documentation
  • Communications coordinator

Depending on the scope of the project, each of these roles may be filled by one or more individuals. Fewer people wearing more hats may fulfill these roles on a smaller project. The length and type of employment may also vary during the course of the project. For instance, the role of the project manager will be much more intense at the onset of the project and will diminish as time progresses. Conversely, the role of the trainer will be weighted toward the latter stages of the project.

If you will utilize in-house staff for any of the support roles, they will likely need to upgrade their skills. The level and depth of training necessary will depend on the roles they perform. A two or three-day training session can usually cover skills required for basic client administration, but technical support training will be much more in-depth, requiring at least five days per staff member. Training needs to take place well in advance of the start of the project to ensure that help desk and other front-line staff will be up to speed when the first support call comes in.

If your staff does not have the necessary skill set, you’ll have to bring it in from an external source. You’ll need to consider these key questions when bringing in outside help:

  • What experience does each candidate have for the role that is required?
  • Has the project manager candidate handled an Exchange migration before?
  • Has the technical staff been trained and, most importantly, had experience with supporting an Exchange 2000 environment?

I believe that selecting the right people, rather than rushing the project, is the key to success. If you must rely on outside staff, do make sure of their commitment to the project throughout its life span. I’ve experienced more project setbacks as a result of responsibility handoffs than from any other factor.
This is the first of a three-part overview of how to plan and implement a migration to Exchange 2000. In the second part of the series, Ric Liang covers upgrading the infrastructure and software. The final article will deal with training and implementation. Please send us an e-mail with your thoughts on the series or post a comment below.