A Strategy for Migrating Multiple E-Mail System Users to a Single Corporate Standard
(Originally published in Messaging Magazine, July/August 1998)

By Doug Shelton and Randy Perrin, Kaiser Permanente

Over the past decade, LAN-connected PCs have replaced mainframe-connected "dumb" terminals on desktops across corporate America, democratizing data-processing resources in ways unimaginable a decade ago. The increase in desktop computing power has revolutionized how we work and communicate with each other—but the accelerating implementation of new technology has made planning challenging.

The proliferation of distinct micro-computing environments, each built around a core of servers and users, has lead to a virtual Tower of Babel in some large corporate cultures. Corporations wanting to project a single corporate identity or to increase integration of previously autonomous business units must find strategies to more tightly couple disparate e-mail systems into a single, interoperating, e-mail environment.

Kaiser’s IT organization has responded to a corporate directive to improve communications among Divisions by integrating its e-mail environment via hub-and-spoke architecture. Gateways from the separate Kaiser e-mail systems in each Division (and within Divisions) now connect to a central messaging hub providing a conduit for messages to move from one e-mail platform to another.

This hub-and-spoke messaging architecture can be thought of as a stage in the evolution of corporate messaging, beginning with a centrally controlled and administered, mainframe-based system as described below.

It is useful to think of the overall evolution of the corporate messaging environment in distinct stages as shown in the diagrams below:

Stage 1: E-mail services are mainframe or minicomputer-based and provided via a
central IT organization.

Stage1.jpg (9601 bytes)

 

Stage2.jpg (10260 bytes)

Stage 2: LANs begin to "crop up" in
various business units.

Stage 3: File-server-based e-mail systems
begin to appear on the LANs. 		Stage3.jpg (13214 bytes)

Stage4.jpg (13899 bytes)

 Stage 4: Client/server versions of these file-server-based, e-mail systems begin to appear.
Stage 5: Point-to-point gateways are installed
to provide message transport between the
disparate systems.		 Stage5.jpg (14488 bytes)

Stage6.jpg (15171 bytes)

 Stage 6: A hub-and-spoke architecture is implemented to increase management and control of cross-platform message transport and to synchronize addresses across systems.
Stage 7: As client/server e-mail systems evolve to enterprise level, the IT organization begins migrating disparate e-mail systems to a single corporate standard. Stage7.jpg (11489 bytes)

 

Benefits of a Single Corporate E-Mail Standard

Moving to a corporate standard, the e-mail platform offers significant benefits over a hub-and-spoke architecture including:

  • Improved message fidelity-a single system supports rich text content rather than the lowest common denominator accepted by gateways, RFC822 flat ASCII text;
  • Sophisticated messaging functionality-features such as priorities, read receipts, error-tracing and others available only in proprietary products and in the newer generation of Extended Simple Mail Transfer Protocol (E/SMTP)-based products are supported. (They are typically lost in SMTP gateway conversion);
  • Improved messaging performance-messages do not have to traverse and be processed by multiple gateways;
  • A single e-mail directory-a single directory eliminates the need for directory synchronization and the latency issues associated with new and changed user entries;
  • A standard server infrastructure-the e-mail server software, the hardware specifications and network operating system can all be standardized; and
  • Additional functionality-e-mail-enabled workflow and other applications, not supported by the hub-and-spoke architecture, would be available to all users.

Migration Strategy

The easiest approach to migration would be to simply replace one e-mail system with another, user by user, forcing each user into isolation from other workgroup members and applications until the entire workgroup is converted. Unfortunately, staff in most corporations rely on their e-mail system and mail-enabled applications to get their daily work done. As a consequence, the easiest approach is not an option.

The proposed strategy puts a high value on high continuing support for e-mail users, avoiding disruption of services, and maintaining users’ contact with others in their workgroup before, during and after migration. In a heavily used environment with high service expectations, this could be compared to the automotive feat of "changing a distributor while the car is running." The timing of migration steps is clearly critical.

The strategy also seeks to reduce unnecessary dependencies in the process, providing the maximum possible latitude in scheduling crucial tasks. For example, scheduling logistics can often make it difficult to tightly couple the tasks of creating each user directory entry with installing the client software, yet creating such an entry in advance presents challenges. For example, the new entry can immediately become a real entity to the system, and mail may end up in the associated mail store long before the user is installed and able to access it.

To address this problem, the migration team may include a field team comprising those who install the e-mail client software and a central organization that plans and schedules the overall migration and creates IDs and address entries in a central directory. They can also control forwarding of mail, which is described in the steps that follow.

Finally, the strategy provides for access to the old e-mail system for some period of time following migration. Migrated users can continue to access e-mail-enabled applications on the old system (which may take some time to completely convert) and can participate in group calendaring and scheduling with users who haven’t yet migrated. This strategy also provides for a simple, quick back out-at least until the old e-mail system client is uninstalled.

The strategy is shown in the following series of diagrams with descriptions of the crucial changes in each. The diagrams use certain types of information that describe the processing and transport of mail at each step of the process as follows:

  • E-Mail flow—shows how messages are passed between the target e-mail system to the old e-mail system.
  • E-mail directory entries—ID entries and message forwarding settings are shown in tables next to the servers.
  • X.500 directory pointers—directory entries that control routing of messages coming into the mail hub are shown in the X.500 directory box.
  • Workstation client status—the client software installed at the end of this migration step is shown on the monitor screen. The active client is shown at the top of the screen. If there is an inactive client installed, it appears at the bottom of the screen.
  • E-mail message storage—messages stored in each e-mail message store are shown in tables next to the server. The diagrams distinguish between "Saved Messages" and "New Messages" to clarify how Saved Messages are migrated as part of the overall process.

Note: In the descriptions of each step, references to components shown in the diagram are capitalized.

Migration Steps

Step 1: A Mixed E-Mail Environment Ready for Migration to Begin.
Jane Doe is using the Old E-Mail Client to send and receive messages. The Old E-Mail System Directory shows a native Address Entry for Jane. Messages to Jane are being saved in the Old E-Mail System’s Message Store.The X.500 Directory on the E-Mail Hub contains entries for Jane that direct all incoming mail to Jane Doe’s Old E-Mail System. It also contains pointers to all users on the Target E-Mail System and to every other e-mail system linked to the Hub. Note that the E-Mail Hub may use a directory structure other than the X.500 standard.
 Step1.jpg (37841 bytes)

Step 2: Address Entry and Message Store Created on Target E-Mail System.
In the diagram, Jane Doe continues to use the Old E-Mail System as described in Step 1, but now she has a native Address Entry on the Target E-Mail System server. That entry is set to forward any mail sent to Jane’s new address through the E-Mail Hub, to her Old E-Mail System Message Store. As a result, Jane’s Doe’s new Message Store will remain empty. The foreign entry for Jane Doe, which previously synched to the Target E-Mail System from the E-Mail Hub, is suppressed. Step2.jpg (40747 bytes)

Step 3: Target E-Mail Client Software Installed on User Workstation.
The Target E-Mail Client is installed on Jane Doe’s Workstation linking to Jane Doe’s Target E-Mail ID created in Step 2. This can be made available on a central directory which the client install process accesses for completion. Although the client could be installed before the ID has been created, that would typically require another visit from the installers to ensure the needed handshakes between the client software and the server component of the ID are accomplished (ID certificates, customized workspace, etc.). Step3.jpg (41017 bytes)
In the diagram, Jane Doe continues to use the Old E-Mail System. She could access the Target E-Mail System, but should not be encouraged to do so until she has been trained and the migration completed.

Local migration staff should schedule training as close as possible to the client install to minimize the likelihood that users will begin using the Target E-Mail System while e-mail is being forwarded to the Old E-Mail System. The presence of the client software on the workstation does not impact mail storage, addressing or message flow.

  

Step 4: User’s E-Mail Identity Switched to Target E-Mail System.
This is the key step in the migration process: After Jane Doe is trained, the central administration team switches Jane Doe’s e-mail identity. Jane is now using the Target E-Mail System as her primary messaging system. All messages coming from the Target E-Mail System, the Old E-Mail System and Other E-Mail Systems route to Jane Doe’s Message Store on the Target E-Mail System. Step4.jpg (30861 bytes)
In the diagram, Jane Doe is now an active user on the Target E-Mail System. Her Address Entry in the Target E-Mail System Directory no longer forwards messages to the E-Mail Hub. Jane Doe’s address entry in the Old E-Mail System directory has been changed to forward incoming messages to the E-Mail Hub and the pointers for Jane Doe in the X.500 Directory now point to the Target E-Mail System. Jane still has access to the old E-Mail System ID and can continue to use e-mail-enabled applications, calendaring and scheduling, and bulletin boards and conferences that may be present on the Old E-Mail System.

After Step 4 is complete, Jane Doe should no longer use her Old E-Mail System for messaging as this can result in reply bounces general confusion about how replies are handled. There are several, potential, programmatic approaches to discourage Jane from reverting to her Old E-Mail System (depending on the specific systems): Prevent her from accessing addresses or sending to users outside the Old E-Mail System; Modify the Mail Hub directory to trigger a non-delivery response when Jane tries to send a message from the Old E-Mail System to a user outside of it; or Disable the e-mail component.

Step 5: Move Saved Messages to Target E-Mail.
There are three options for migrating e-mail stores from the Old E-Mail System to the Target E-Mail System: If a workstation-based migration tool is available: a central administration team accesses Jane Doe’s ID and password and (presenting themselves to the system as Jane) moves saved messages from the Old E-Mail System Message Store to the Target E-Mail System Message Store. This is the preferred strategy because it retains message format. Step5.jpg (31833 bytes)
If no workstation-based migration tool is available: a central administration team (or field support staff) forwards Jane’s saved messages from the Old E-Mail System Message Store through the gateways to the Target E-Mail System Message Store. This approach is less desirable because addressing information is changed and content other than ASCII is stripped out as the Saved Messages traverse the gateway.

Saved Messages can also be manually cut and pasted via a Graphical User Interface (GUI) from the Old E-Mail System Message Store into the Target E-Mail System Message Store. This is a time-consuming approach and address information is not converted, but the rich text content can be (somewhat) preserved.

In the diagram, the only change is that Jane Doe can access all saved and new messages in the Target E-Mail System Message Store. The old Message Store is empty.

Step 6: Delete Old E-Mail Client.
This step takes place only once Jane Doe’s e-mail enabled applications, calendars, schedules, bulletin boards and conferences and all her workgroup members have been migrated to the Target E-Mail System. Recreating Jane Doe’s e-mail applications on the Target E-Mail System (or some other available platform) is typically the most time-consuming task in the migration and the main reason the Old E-Mail Client is maintained after Jane’s identity has been switched. Step6.jpg (26795 bytes)
Field on-site support staff delete, (and preferably, archives in a local file server or tape backup) the Old E-Mail System Client from Jane Doe’s workstation. A central administration team deletes (and also archives) Jane Doe’s Old E-Mail System account. This step needs to initiate a process at the E-Mail Hub to create a Foreign Address Entry for Jane Doe in the Old E-Mail System Directory.

In the Workflow Application this step will not take place until a local field on-site support staff technician has signed off that Jane is now independent of all Old E-Mail System applications.

In the diagram, Jane Doe no longer has access to the Old E-Mail System. All necessary messaging and e-mail system-based applications are operating on the Target E-Mail System.  

Summary

Details of the described approach will vary depending on the capabilities of the various e-mail systems involved. This strategy addresses the key steps for migrating users in most integrated e-mail environments while maintaining uninterrupted support for e-mail users and their workgroups.

While the thrust of this article is to describe a migration strategy, there is a potential 8th stage in the evolution of messaging systems—and one which Kaiser is preparing to make: Implementing modular, standards-based messaging components. This step is intended to allow piecemeal connectivity of disparate messaging products with full—or acceptable—fidelity, and provide directory addressing for all e-mail systems from any of the standards-based clients. In such an environment, the directory synchronization and gateways—and their associated problems—are eliminated.

The Proposed Future Messaging Environment diagram below shows a model for such a future environment: one based on the predominant U.S. Internet standards.

Routing.jpg (28218 bytes)

The model shown in this diagram employs the following major concepts:

  • E-Mail Transport: all vendor products in this environment employ SMTP- and E/SMTP-based Message Transfer Agents (MTAs). There are no (external) gateways: either the products include native SMTP MTAs or they translate messaging content and functions (e.g., return receipts, error codes, etc.) with acceptable fidelity.
  • Directory Access: all vendor products also support Lightweight Directory Access Protocol (LDAP) on their clients and e-mail directories. Clients access one central directory (which may be X.500-based) to obtain other user’s e-mail addresses. These, in turn, are extracted in real time using of LDAP connectivity from the central repository to the proprietary (but LDAP-accessible) e-mail directory.

The key to managing a large e-mail environment such as the one in Kaiser Permanente is to keep abreast of the evolving technology and make appropriate plans to employ it at the right times. Evolution of vendor products towards common standards is providing significant opportunities for corporations to effectively manage a multiple-vendor, well-integrated messaging environment that can approach the functionality and convenience of a single corporate standard. Given the profusion of LAN-based messaging products in corporations worldwide, this may be a more realistic vision of the future for the corporate messaging environment.