How to Perform an Exchange Migration

In this phase, existing mail accounts and messages are migrated from the existing messaging environment to the Microsoft Exchange 2003 environment. Your migration strategy must be executed in a manner that is transparent and that has the minimum possible impact on your current e-mail users.

To accomplish these goals, an effective migration strategy and appropriate migration tools must be designed and implemented. They must address all aspects of system migration, including networking, external interfaces, account synchronization, management systems, and parallel operations.

This chapter contains the following sections:

Developing a Migration Strategy

Preparing the Migration Plan

Using Migration Utilities

Tips for a Successful Migration

Refer to the Microsoft Exchange 2003 Migration Guide for complete information on migration.

Developing a Migration Strategy
The typical site where Microsoft Exchange 2003 is installed has an existing mail system that provides messaging services to its users. Migration is the act of moving or copying the data for all users from the legacy (existing) system to the Microsoft Exchange 2003 system. Migration is performed so that all customers can be serviced by the Microsoft Exchange 2003 system, not simply those new subscribers following the installation of Microsoft Exchange 2003.

Migration is the most complex facet of any deployment project. Even though this document provides a framework to follow for migration, no two migrations are exactly alike, due to the differences in each site's legacy mail system and its integrated systems and procedures. A successful migration depends upon accurately identifying all unique aspects of the system that are to be duplicated in Microsoft Exchange and then duplicating these conditions through development and testing prior to the actual physical migration.

The principal issues of concern in any migration to a new mail service are data integrity and transparent cutover to production. Data integrity guarantees that all mail accounts, stored messages, and associated personal information and preferences (for example, address books, passwords, and so forth) are accurately retained in the new mail system. Transparent cutover to production means that the transition is handled quickly, cleanly, and with no disruption to the end-user experience.

In typical migrations, the total amount of time required for a successful transition is a function of system complexity. Both the total number of mail accounts and the total number of stored messages are significant factors. In addition, migration time can be affected by system and site-specific issues.

Any migration strategy must address:

Migrating accounts

Migrating mailboxes

Migrating Accounts
This migration involves all of the information that uniquely identifies and describes a user, including class-of-service data that defines the service for which users are subscribed. Account data must be placed in the Microsoft Exchange 2003 system before message data. The first task is therefore to collect and transfer account data from the legacy system and then transfer it to the Microsoft Exchange 2003 system.

If your legacy system has domains and organizational units, you must prepare to migrate these also.

Migrating Mailboxes
This migration involves message data--the actual messages to be migrated that belong to the user. The mailbox is simply a collection of the messages belonging to a particular account.

Preparing the Migration Plan
Migration involves significant planning, more so than any other deployment task. This planning is necessary because the activity is exposed to existing users and will, in most cases, be the initial experience that users have of the new system. It is very important to plan for every eventuality in order to avoid problems during the migration.

Refer to Appendix A for information on how to obtain a sample migration plan.

Migration is 95 percent planning and 5 percent execution. A multitude of factors that must be considered in order for a migration to succeed.

The Migration Plan provides a detailed, step-by-step procedure for migrating accounts and mailboxes to Microsoft Exchange 2003. The deployment team should make several dry runs of this plan, with each dry run resulting in a subsequent refinement of the plan.

Any migration plan should address these considerations:

Ensuring systems readiness

Coordinating with other groups and identifying dependencies

Verifying software installation and configuration

Setting up the test system

Providing provisioning connectivity

Testing the migration

Choosing full or limited migration

Resuming service

Ensuring Systems Readiness
All systems to be tested must be ready and operational before testing begins. In addition networks must be implemented as defined in the architecture design (see Chapter 2).

For each original e-mail system, separate IP settings (each with unique "A" records in the DNS) must be established for the following:

Host Address This is the permanent IP assignment for the host.
Service Address This is the address that is used by all e-mail clients for a service. The Service Address will be re-assigned to Microsoft Exchange at the time of account migration.
Service Proxy Address There must be a Service Proxy Address for each Service Address. The IP number used for any Service Proxy Address will match its respective Service Address. The Service Proxy Address will be used for proxy targeting where proxy is used on the Microsoft Exchange system. These can be de-assigned after all migrations are complete and when it is determined that a revert procedure is not required.

Coordinating with Other Groups and Identifying Dependencies
Since any migration touches upon many aspects of a company's operations, make sure you coordinate the migration with all affected groups and identify dependencies--that is, determining the order in which systems should be migrated.

Verifying Software Installation and Configuration
In addition to installing Microsoft Exchange 2003 (see Chapter 3) and verifying that all components inter-operate, you must set correct Microsoft Exchange environment settings for the root user. These include the correct $PATH, $LD_LIBARARY_PATH, and $Microsoft Exchange settings in order to access the Microsoft Exchange migration tools.

Setting Up the Test System
To validate a migration plan, the test system should have the capacity of production systems, including the proper storage volume configuration and failover configuration (service continuity). The test system must have Internet connectivity, as Proxy mode operations cannot be tested without this.

Aside from equipment that mimics the production system, test driver machines must also be available to power the migration and capacity tests. The test drivers must be configured with migration utilities as well as with mail clients or other test utilities for accessing and sending mail.

At least one test host is required for migration testing; this host acts as a surrogate for the actual online e-mail hosts and holds all mailbox data required for testing.

Providing Provisioning Connectivity
The provisioning interface must be validated before migration can occur. C API procedures should be tested to ensure that modifications performed on the ISD are successful and are propagated to the provisioning database. The Perl API set for batch account migration also must be tested. Last, administrative routines in the provisioning system or ISD must be validated.

This testing is performed in a dual provisioning environment. The purpose of dual provisioning is to ensure the ability to revert to the legacy mail system in the event that the new mail system in not successful.

For provisioning, automatic mailbox creation must be tested. Zero-length mailboxes are typically not migrated; rather, they are turned on in Microsoft Exchange 2003. The first time mail is received or checked, the mailbox can be created. A large test database (representing the volume of anticipated accounts) must be test-migrated to ensure that the procedure works and that the destination ISD database can handle it.

If possible, you should identify a group of "friendly" users willing to assist in identifying any problems or errors

Testing the Migration
Before the migration can occur, comprehensive testing on the production system must be completed. Migration test activities are "non-intrusive" to the existing mail system and are conducted from a separate system using actual user account information and a test copy of the production user data.

The procedures for extracting account data from the legacy system must be tested. The method and utilities to load these accounts into the ISD must be validated through testing. Each class of service must be included, as well as each combination of account attributes, such as forwarding, aliases, and vacation replies.

In addition, the process of moving mailboxes to the Microsoft Exchange 2003 system must be tested. This process includes the method of suspending the account, the physical transfer of messages and attachments, and the return of the account to active status.

You should make any possible configuration changes to prevent network or system loading. In addition, you must establish any special network, host, or storage accommodations that may be required for testing. A special network configuration may be required to prevent traffic complications introduced by migration testing. Another solution may involve localization of the original mailbox storage to the Microsoft Exchange 2003 system.

--------------------------------------------------------------------------------

Note: Depending on the particulars of a given migration, you may need to create new scripts or modify existing migration scripts. All scripts for managing batch processes must be completed and tested prior to migration.

--------------------------------------------------------------------------------

Choosing Full or Limited Migration
Accounts to migrate can be defined based on business rules (for example, all mail accounts in good standing or priority accounts requiring early access to features not offered in the exiting mail system).

If you are not going to migrate the entire population at one time, there are certain considerations you need to plan for. For limited migration, you must configure the Microsoft Exchange 2003 system for POP proxy in order to retrieve mail from the legacy system for unmigrated accounts and mailboxes. The architecture must also account for SMTP relay during Proxy mode in order to deliver appropriate mail to the legacy system as well as to Microsoft Exchange 2003.

The method of migrating account data must be identified and tested. Before the limited account migration can occur, a back-out plan, migration quality assurance, and certification of migration must be resolved and validated by testing.

In many instances, new subscribers to mail service at the customer site are added to the Microsoft Exchange 2003 system before migrated accounts from the legacy system. The benefits of handling new registrations in Microsoft Exchange 2003 are that you may be able to:

Offer differentiated service immediately.

Introduce Microsoft Exchange 2003 at a measured pace.

Ensure that no more users are added to an obsolete system.

Resuming Service
Once migration is completed, accounts are automatically switched from Proxy mode to active status. Users regain access to their mailboxes and all messages that were deferred during migration are delivered to their intended recipients. In addition, you must move operations entirely to the Microsoft Exchange 2003 system and deactivate the legacy system.

A burn-in period should be identified, over which the Microsoft Exchange 2003 system must be closely monitored for error conditions.

Using Migration Utilities
There are multiple methods for the combined migration of accounts and mailboxes. One method is to transfer all accounts in a single migration. Then, mailboxes can be transferred in batches. Another method is to transfer a batch of accounts, then transfer a batch of corresponding mailboxes, and so on.

Utilities that support the chosen strategy must then be developed and tested. These tests should include timing of the execution of these utilities.

This phase involves the building of the migration utilities themselves and must include the design, development, and testing of the migration utilities that are to be used to migrate the mail from the existing system to the newly implemented Microsoft Exchange 2003 system. New tools have to be built very often because of the different source mail systems that can be in existence.

Microsoft Exchange 2003 offers automated migration tools designed to streamline the process of moving your service, including built-in tools for services using Sendmail and Software.com's Post.Office. These flexible, modular, and customizable tools are Perl scripts that handle the export of directory, mailbox, and user information from these other systems to files in Microsoft Exchange 2003-readable format (based on LDIF), which are then imported into Microsoft Exchange 2003. These tools enable you to migrate all accounts at once or as incremental blocks of users. When migrating from a different mail system such as Netscape Messaging Server or SIMS, Microsoft Exchange 2003's proxy features and robust export command set provide a solid foundation for rapid development of custom export scripts.

Tips for a Successful Migration
With the completion of the migration tests, the only anticipated impact will be caused by the difference in functionality between mail systems. Once the migration of accounts has started, the target production environment becomes the production environment.

The migration procedure involves these discrete steps:

Setting up Microsoft Exchange 2003 in Proxy mode

Changing the MX record

Identifying accounts to be migrated

Extracting account information

Creating accounts in Microsoft Exchange 2003

Migrating messages

Setting Up Microsoft Exchange 2003 in Proxy Mode
Microsoft Exchange must be configured for Proxy mode prior to activating the system. The proxy configuration permits the relay of message and service requests to the legacy system until the full migration has been achieved.

In Proxy mode, all incoming mail is directed to Microsoft Exchange 2003. If the mail is for a user that does not have an Microsoft Exchange account, the mail is relayed to the legacy system for delivery. If a user attempts to retrieve mail, but the user's mailbox is not yet located on the Microsoft Exchange 2003 system, the POP server will connect to the legacy system and will retrieve the mail from the legacy mailbox location.

Changing the MX Record
In order for mail to reach the Microsoft Exchange 2003 system (instead of the legacy system), you must change the MX record in the DNS for the mail domain of the site, so that traffic is directed to Microsoft Exchange 2003.

With all of the mail directed to Microsoft Exchange, you can begin to burn-in the system with live loads and become accustomed to operations administration even if there is no account data in the system. However, as soon as the system is activated, accounts are provisioned directly into Microsoft Exchange 2003.

--------------------------------------------------------------------------------

Note: This step can take a few hours to be propagated over the Internet.

--------------------------------------------------------------------------------

Identifying Accounts to Be Migrated
The first step in migration is to determine which existing mail accounts will move to the Microsoft Exchange 2003 system. Accounts to migrate can be defined based on business rules (for example, all mail accounts in good standing, or priority accounts requiring early access to features not offered in the existing mail system).

Extracting Account Information
After defining the accounts to migrate, the next step is to extract account information from the existing mail system. Using the target account list, account information is exported into a file in LDAP Data Interchange Format (LDIF). The standard LDIF format permits the importing of account information from any existing mail system to an Microsoft Exchange system. The scripts used here can be customized to handle any situation.

Creating Accounts in Microsoft Exchange 2003
Next, accounts are created in the Microsoft Exchange directory based on the account information described in the LDIF file. As accounts are created, they are placed in Proxy mode, causing mail delivery to and access from unmigrated accounts to be passed directly through to the old mail system, thus ensuring continuous service to end users. During this phase, if a user logs in and supplies an unknown username, the Microsoft Exchange POP server connects to the current e-mail system.

Migrating Messages
The last phase of migration involves moving mail messages from the existing mail system to the Microsoft Exchange system. Message migration may occur either as separate files or as a single, concatenated file. However, some customization is typically required, since the way a message is stored in the Message Store Server (MSS) can differ from the standard mail format. This phase requires new accounts to run in Maintenance mode, during which time these mailboxes are unavailable. For this reason, message migration is typically performed in small increments during off-peak hours.

Exchange Migration plan for moving forward:

Perform Due Diligence on your network via Remote Terminal Service ( Next Week)

Identify existing components - users, groups, login variables

Document proposed AD structure

Project kickoff meeting (Friday)

Install Windows Server 2003 (Friday Night)

Install Active Directory (Friday Night)

Configure, Patch and Connect (Friday Night)

Review Event Log, resolve any errors (Friday Night)

Connect AD environment to existing Windows 2000 (Friday Night)

Identify existing printers (Saturday)

Identify existing components in Exchange (Saturday)

Build Exchange, configure, patch(Saturday)

Install and configure virus software,Spam solution and Fax

Software(Saturday)

Configure OWA in DMZ(Saturday)

Verify Installation (Saturday)

Perform Mailbox Move (Saturday)

Install Outlook 2003 on all desktops. (Saturday - Sunday)

Review Event Log, resolve any errors (Sunday)

Setup Test workstation/perform testing (Sunday)

On-Site to handle any issues with the migration (Monday)

The above steps are only an estimate of work needed to be perform a successful migration. After we perform the Due Diligence Intercore will have a more definite outline in MS Project to fully detail the breadth of work needed to perform the migration . This Due Diligence will identify issues that we can resolve before the migration is performed.

InterCore Technologies, LLC opened it's doors in May of 1996. Our mission: To Provide a high level of computer consulting services using the most experienced engineers at fair prices. We believe in using a Business Value approach to every aspect of computer consulting. This provides our clients with the most cost effective solutions. We help our clients get more with their current technology investment. Click here to see why Intercore is different from other firms