Chapter 1
Creating a Migration Strategy
Migration is the process of moving your existing electronic mail system to Microsoft Exchange Server. This process involves copying mailboxes, distribution lists, public folders, messages, attachments, calendars, and addresses from your existing system to Microsoft Exchange Server. Planning is critical, to prevent downtime and data loss.
This chapter provides an overview of the factors you need to consider when planning and testing a migration strategy. Microsoft supports migration from the following systems:
	Microsoft Mail for PC Networks, version 3.x
	Microsoft Mail for AppleTalk Networks, version 3.x
	Lotus cc:Mail, database version DB6
	Verimation MEMO MVS, version 3.2.1 or later
	IBM PROFS/OfficeVision, all versions
	Digital ALL-IN-1, versions 2.3 or later

Microsoft provides several programs that work with your existing system to copy and import addresses, mailboxes, messages, shared folders, and scheduling information, as follows:
	Source extractors
Source extractors copy directory, message, and scheduling data from existing systems to a migration file format.
	Migration Wizard
The Migration Wizard imports data in migration file format and acts as the source extractor for Lotus cc:Mail and Microsoft Mail for PC Networks.
	Administrator program
The Administrator program is a graphical interface that includes import and export commands.

Note
Microsoft Exchange Server uses programs called source extractors to copy messages from one system to the other. If your system is not listed on page 1, contact your Solution Provider or Microsoft Consulting Service to find out whether a third party provides a source extractor. If a source extractor isn’t available, you can create your own. For more information, see Appendix B, “Creating a Source Extractor.”
Throughout this guide, the term existing system refers to the messaging system you are migrating from.
Planning Overview
Before you begin migrating, you need to analyze your needs and create a strategy. First, you need to create a team of experts who can help your rollout go smoothly. Next, you need to decide whether your organization will migrate all at once or in phases. You will also need to determine how you plan to:
	Establish and maintain connections.
	Convert messaging applications.
	Maintain external addresses.
	Establish naming conventions.
	Handle migrated messages.
	Maintain directories.
	Move scheduling information.
	Move distribution lists.
	Route external messages.
	Move remote users.
	Create a contingency plan.
	Test your plan.

Creating a Migration Team
Your rollout will be more efficient if each member of your team has specific responsibilities related to his or her expertise. You should assign team members with the responsibilities that are outlined in the following table. You may also need additional support people immediately after migrating a large group of users. You might want to train a few extra people to be local experts in each group of your organization.
Team Member	Responsibilities	
		
System architect	Coordinates the design, testing, and implementation of Microsoft Exchange Server at each site.	
Hardware installation and support specialist	Upgrades client and server computers.	
Windows NT Server and Microsoft Exchange Server support specialist	Keeps the servers running, backed up, and optimized.	
Client desktop support specialist	Solves client problems.	
Network and telecommunications specialist	Understands the existing network, telephone, and modem needs.	
Help desk trainer	Trains the support staff to use Microsoft Exchange Server.	
End user trainer	Trains end users to use Microsoft Exchange Server client components.	
Testing and implementation specialist	Tests the migration plan and rolls out Microsoft Exchange Server.	
Coexistence specialist	Understands the existing system and how it interacts with Microsoft Exchange Server.	
Application upgrade specialist	Implements or replaces the existing system’s applications in Microsoft Exchange Server.	
Rollout consultant	Consults with you during implementation of Microsoft Exchange Server. To find a consultant, contact Microsoft Consulting Service and consulting firms that have Microsoft Solution Provider status.	
Training specialist	Handles the standard installation questions. 	

Choosing When to Move Users
There are two ways to move from your existing system: single-phase migration and multi-phase migration.
Single-Phase Migration
Single-phase migration moves everyone at one time, and may be better for your organization if:
	There is little or no data to move from your existing system.
	Your organization has the resources to move everyone at once.
	All hardware and software required to run Microsoft Exchange Server and client are in place.

Multi-Phase Migration
Multi-phase migration moves users in groups, at different times. If your existing system is large, you may not be able to switch everyone to Microsoft Exchange Server at once. The following figure shows a system during multi-phase migration.
	
Once you start moving mailboxes, the existing system coexists with Microsoft Exchange Server until you move all the mailboxes. After the first group of users is migrated, the systems must coexist until the last group of users is migrated.
	
Multi-phase migration may be better for your organization if:
	Not all departments can upgrade at the same time.
	You need to free up hardware in early phases for redeployment
during later phases.
	Your organization can’t migrate everyone within an acceptable
downtime period.

If you’re doing a multi-phase migration, you need to develop a plan for coexistence that supports both systems. 
Establishing and Maintaining Connections
The existing system and Microsoft Exchange Server must be connected either by a gateway between them or by gateways to a common backbone, such as an IBM PROFS system or the Internet. Your strategy should address the following concerns.
Increased message traffic may cause a problem
When some users are on your existing system and some are on Microsoft Exchange Server, message traffic increases and may cause a bottleneck.
	
To avoid this problem, you can:
	Configure multiple gateways.
	Move groups of people together who typically exchange mail.
	Restrict message size.
	Connect new sites quickly to avoid sending mail between Microsoft Exchange Server sites that are backboned over the existing system.
	Dedicate fast computers to the gateway processes.

Some features may not be supported
The gateway connecting the two systems may not support all the features available with Microsoft Exchange Server or your existing system. For example, custom forms convert to standard text messages when crossing some gateways. Groups that use such features should be moved together.
The connection may be unstable
If your connection is unstable:
	Consider using a different gateway, a backbone, or a common foreign system. 
	Use monitors to assess message traffic and queue size.
	Keep traffic across this connection to a minimum.
	Minimize the length of time that this connection will be used.

Converting Messaging Applications
As part of your strategy, evaluate your existing messaging applications. Microsoft Exchange Server supports applications based on the Messaging Application Programming Interface (MAPI) and Common Mail Calls (CMC). You can replace some workgroup applications with public folders or custom forms. Other applications can be modified to work with MAPI.
When you decide to migrate an application, consider the following issues:
	How does the application interact with the existing system?
	Can you replace the application with public folders or custom forms, or modify it to use MAPI?
	Is this application needed across platforms?
	Does the application need to coexist during multi-phase migration?

For more information, see Microsoft Exchange Server Application Designer’s Guide. 
Using MAPI Service Providers
Microsoft Exchange Client can be used with different e-mail systems by installing a MAPI service provider, which is an interface between MAPI and another e-mail system.

Note
If a MAPI service provider is available for your existing system, consider first moving your users to the new clients and then using MAPI service providers to supply MAPI 1.0 connectivity between the Microsoft Exchange Client components and your existing system. For more information about support for your existing system, see the appropriate system chapter later in this book.

Research how people use your existing system to be sure that you have covered all applications. You might solicit feedback from MIS staff and users in your company.
Maintaining External Addresses
If your users often receive mail from outside your organization, or from other systems within your organization, your users’ external addresses should be preserved. For example, if your existing system receives e-mail from the Internet, every mailbox in your system has an SMTP address. With proper planning and tools, you can attach SMTP addresses to the migrated mailboxes. If you choose not to preserve these addresses, all users must provide their new addresses to everyone with whom they exchange e-mail.
Establishing Naming Conventions
If your existing system doesn’t have naming conventions, consider establishing conventions before moving to Microsoft Exchange Server, especially for directory names, display names, given names, last names, and aliases.
The directory name is also known as the common name. It is used to create the unique full directory name of a mailbox. This name is visible only in the Administrator program. By default, the directory name is the same as the alias name, with the exception that it can’t contain spaces.
The following table lists common conventions for directory names.
Directory Name	Example	
		
Alias	TJohnston	
Employee number	72345	
Network user ID or account name	KIRMSE	

Important
Since directory names can’t be changed, you should determine the convention before creating mailboxes.

The display name appears in the Address Book, and you can change it any time. The display name might confuse users who are accustomed to seeing abbreviated names. It is best to change the display name convention during migration.

Important
Migrated messages use the display names of the sender and recipients. If you change the display name during migration, replies to migrated mail may not associate the old display name with the new display name and address.

If you use the old naming convention for custom recipients and a new naming convention for the mailboxes, replies to migrated messages are delivered, but display names may be harder to find. For example, if you are switching the display name convention from “Last, First” to “First Last,” senders may have to search the list twice to find the recipient.
The following table lists common conventions for display names.
Display Name	Example	
		
<First Name> <Last Name>	John Smith	
<Last Name>, <First Name>	Smith, John	
<First Name> <Middle initial> <Last Name>	John Q. Smith	

By default, the first name and last name are used to create X.400 e-mail addresses. Your naming convention should state whether nicknames should be listed as the first name or as the display name. You also need to consider how to treat hyphenated and duplicate display names.
By default, the alias is used to create SMTP (Internet) and Microsoft Mail e-mail addresses. The alias is visible to the public and can contain spaces, unlike the directory name. To reduce confusion later, consider making this name unique in the Recipients container.
The following table lists common conventions for alias names.
Alias Name	Example	
		
<First Initial> <Last Name>	JSmith	
<First Initial>(space)<Last Name>	J Smith	
<Last Name> <First Initial>	SmithJ	

Each source extractor has a default method for mapping existing names to new Microsoft Exchange Server display and directory names. You may want to check the default mapping of your source extractor. You can modify the extracted data or the new mailboxes. For more information about how the source extractor works with your existing system, see the chapter pertaining to your existing system later in this guide.
Handling Migrated Messages
After you migrate a mailbox, the old mailbox may receive mail that was in transit. Some systems can forward mail or reply to the mail with the new address. If your existing system doesn’t have these features, have users periodically connect to their old mailboxes, or use the source extractor and the Migration Wizard to forward the mail. For more information, see the chapter pertaining to your existing system later in this guide.
When a user replies to a migrated message, there are three possible results:
When	Result	
		
A display name matches the display name in the message	The address is resolved.	
More than one display name matches the display name in the message	The user is presented with a list of choices.	
No display name matches the display name in the message	The user needs to find the new address in the list.	

For a user to be able to reply to the migrated message, you must have all names in the Microsoft Exchange Server address list, either as custom recipient addresses for users on the existing system or as mailboxes for users on the new system, but not as both. Any mail moved from your existing system contains the sender’s and recipients’ display names.
Maintaining Directories
Directories (address lists) change during migration. The Microsoft Exchange Server address list is managed on a site-by-site basis for efficient administration. When a new recipient is added to a site, that information is replicated to all servers in all sites in the organization.

Note
In Microsoft Exchange Server, user addresses in the existing system are considered custom recipients.

During multi-phase migration, you must make directory changes to keep mail flowing. Directories on both Microsoft Exchange Server and your existing system can be kept updated through directory synchronization, which is discussed in later chapters.
You need to update the directories on both systems each time you migrate mailboxes. For example, if you import addresses as custom recipients during the first phase of migration, you must later remove these addresses when you migrate those users’ mailboxes. You should create the custom recipients in the same container as the new mailboxes, so that the Migration Wizard can automatically remove the custom recipient addresses.
You may need to replace old addresses in the existing system directory with new addresses so that old mailboxes stop receiving mail.
Moving Scheduling Information
If your existing scheduling application supports resource accounts (for example, for reserving meeting rooms), you must move these accounts. Some of the Microsoft Exchange Server tools move resource accounts and their calendar data to Schedule+, but some configuration may be required. After you migrate the resource accounts, a user with mailbox rights must open each mailbox and each schedule and configure the Schedule+ properties. 
For more information, see Appendix A, “Configuring Scheduling Resource Files.”
Maintaining Distribution Lists
During multi-phase migration, when lists and addresses are changing, you can ensure correct routing to distribution list members by using one or more of the following methods:
	Migrate distribution lists to Microsoft Exchange Server before moving the mailboxes. (This may be the best choice, because custom recipients are automatically converted to mailboxes.)
	Set up a forwarding scheme.
	Convert distribution lists to public folders.
	Maintain duplicate lists on both systems.
	Disable distribution lists until migration is complete.
	Update the existing lists frequently.

Note
Most source extractors do not migrate distribution lists. See the appropriate chapter for information about your source extractor.
Throughout this guide, the term existing system refers to the messaging system you are migrating from.
Moving Distribution Lists
After gateways and directory synchronization processes between your existing system and Microsoft Exchange Server are working properly, you can move distribution lists.
The following figure shows a distribution list during early migration. As users are moved, the Migration Wizard replaces custom recipient addresses with new Microsoft Exchange Server addresses.
	
The next figure shows the same distribution list during later migration.
	
The Migration Wizard can only update distribution lists in the same site in which the custom recipients are created. For this process to work smoothly, create all first-level distribution lists, such as teams or workgroups, in the site where the custom recipients and mailboxes for those teams are created. Higher-level distribution lists, such as for company divisions, are composed of first-level distribution lists. Therefore, they can be created in the central site, because they have no custom recipients or mailboxes as members.
Setting Up a Forwarding Scheme
Instead of maintaining distribution lists during migration, you can preserve the existing distribution lists and mailboxes until your move is complete. Then you configure the existing system to forward all mail to the new Microsoft Exchange Server mailboxes.
	
Benefits and Limitations
The benefits of this method are:
	Maintenance is not required during migration.
	You can solve problems related to gateway pass-through, replies to sent mail, and personal address books.

The limitations of this method are:
	You have to re-create the distribution lists on Microsoft Exchange Server when your move is complete.
	Messages sent from Microsoft Exchange Server to distribution lists with members on Microsoft Exchange Server cross the connection twice.
	Messages are forwarded individually, leading to multiple copies in Microsoft Exchange Server.

Converting Distribution Lists to Public Folders
You can use public folders to replace distribution lists, so that users can view a history of recent messages in a public folder. To move users from distribution lists to public folders, perform the following steps:
	1.	Create public folders that correspond to distribution lists on your existing system.
	2.	Add a rule on each public folder to forward all new items to all members of the distribution list who have mailboxes that have not been migrated to Microsoft Exchange Server.
	3.	Give user permissions on a public folder to all Microsoft Exchange Server members of the corresponding distribution list.
	4.	After the name of a public folder is visible in the existing system, remove the corresponding distribution list.

Benefits and Limitations
The benefits of this method are:
	New users see a history of recent mail.
	The transition to public folders is part of migration.

The limitations of this method are:
	All the rules and permission maintenance must be done from the Microsoft Exchange Client; changes aren’t made automatically.
	Mail sent to the public folder from the existing system crosses the gateway twice to reach members on the existing system.

Maintaining Duplicate Distribution Lists
To keep network traffic to a minimum, you can have copies of the distribution list on both the existing system and Microsoft Exchange Server. Distribution lists are excluded from directory synchronization between the two systems to avoid duplicate names in the address lists. Only the Microsoft Exchange Server distribution lists appear in its address list, and only the existing system’s distribution lists appear in its directory. This method works well if you use an automated process to modify distribution lists.
	
Benefits and Limitations
The benefits of this method are:
	Custom recipients are updated automatically in the Microsoft Exchange Server distribution lists, with the same rules and exceptions.
	When migration is finished, the complete distribution list is already on Microsoft Exchange Server.
	Mail sent to the Microsoft Exchange Server distribution list is handled by Microsoft Exchange Server, so only one copy of each message is delivered to each messaging system.

The limitations of this method are:
	Your existing system may lack distribution list features.
	Maintaining duplicate lists can require more effort than maintaining one distribution list on one system.

Disabling Distribution Lists
You can save the list of distribution list members and then delete or disable all distribution lists. After migration is complete, you create the distribution lists on Microsoft Exchange Server with new addresses. This requires no maintenance during migration but may disrupt normal e-mail traffic.
Benefits and Limitations
The benefits of this method are:
	Fewer resources are needed during migration.
	No maintenance is required during migration.

The limitation of this method is:
	Some groups may have a critical need for distribution lists and cannot wait for a slow, multi-phase migration to be completed.

Updating Distribution Lists
You can keep distribution lists on the existing system and update them after each phase of migration. This works well if you use an automated process of modifying the distribution list to include new addresses and to remove the old addresses.
	
Benefits and Limitations
The benefit of this method is:
	Less effort is required before migration.

The limitations of this method are:
	Your existing system may lack distribution list features.
	You have to re-create all the Microsoft Exchange Server distribution lists at the end of migration.

Routing External Messages
You can route messages to a foreign system through your existing system or through an intermediate system.
Routing Messages Through Your Existing System
If your existing system has a gateway to a foreign system, Microsoft Exchange Server users may be able to send and receive mail by using your existing system as a backbone to the foreign system. This depends on your existing system, and the gateway or connector that links it to Microsoft Exchange Server. For example, all MS Mail (PC) gateways can be used this way, because the MS Mail connection and MS Mail (PC) support backboning.
	
You need to test any configuration that uses the existing system as a backbone. Consider the following:
	Will mailboxes on Microsoft Exchange Server have addresses for this gateway?
	How will mail for Microsoft Exchange Server mailboxes be routed through the existing system?
	Will migrated mailboxes be able to retain their old external addresses without having routing problems?
Routing Through Microsoft Exchange Server
The alternative is to connect a Microsoft Exchange Server connector or gateway to the foreign system. Users on the existing system can exchange mail with the foreign system through Microsoft Exchange Server. This depends on the existing system, and the gateway or connector that links it with Microsoft Exchange Server.

To use Microsoft Exchange Server as a backbone, you must do either of the following: 
	Configure the custom recipients of existing system users with their old external addresses.
	After creating the custom recipients, inform the users of their new external address, and advise them to provide their new address to everyone with whom they exchange mail. 
Moving Remote Users
Your plans should include users who access mail from remote locations and users at branch and foreign offices. For remote users, consider the following:
	Whether hardware and software upgrades will be required.
	Whether hardware will be purchased locally or in a central site.
	How and when remote users will be moved and trained.
	How routing and directories will be maintained during migration.
	Whether planning and implementation will be handled by local teams or by a mobile team.

Microsoft Exchange Server is available in many languages. All Microsoft Exchange Server computers can support any Microsoft Exchange Client.
Creating a Contingency Plan
Using a contingency plan can minimize downtime if problems occur, such as hardware failure or network trouble. Consider the following guidelines in your contingency planning:
	Anticipate problems and account for resources.
	Keep spare parts handy, or make sure that you can obtain them quickly.
	Plan to back up both the old and new systems.
	Devise a method and a schedule for restoring these backups.

Testing Your Plan
Once it is complete, you should test your plan to validate your strategy, find any missing steps, and familiarize your team with the product and the procedures. To test your plan, use the following guidelines:
	Move the test team first. Make sure they can use the old and new systems at the same time. 
	Find out how fast directories synchronize in your site.
	Determine the throughput of data from the Migration Wizard and gateways.
	Test whether public folder applications can replace some system applications.

The test team should consist of administrators and users working from Microsoft Exchange Client computers, because administrators will be maintaining Microsoft Exchange Server. They should understand how migration affects the day-to-day use of e-mail and how messages are routed both inside and outside the organization. During testing, administrators should set policies on new features, such as public folders, rules, scheduling, and security. They should also become familiar with the following documents and tools:
	Microsoft Exchange Server Concepts and Planning Guide
	Microsoft Exchange Server Administrator’s Guide
	Getting Started public folder
	Online Help in Administrator program
	Windows NT Server documentation
	System Management Server documentation, if appropriate

Testing Directory Maintenance
During testing, address the following questions about maintaining the directory:
	What directory maintenance is required during multi-phase migration?
	What is the best way to migrate or update distribution lists?
	How can existing addresses known to users in foreign systems be preserved?
	How can backboning through Microsoft Exchange Server reduce directory maintenance?