Monday February 09 2004

FreeEmailMigrations.com

WHAT'S NEW

ABOUT

• Purpose & Concept
• History
• Why?
• Disclaimer

SOFTWARE

• Rocket
• Spark
• GroupWise Bulk Migration Tool
• Tools

DOCUMENTATION

• The Basics
• THE ULTIMATE ROCKET GUIDE!
• Rocket Configuration Guide
• Rocket End User Guide
• Rocket Sales Kit
• Rocket SOW
• Rocket Project Plan

KNOWLEDGE

A MIGRATION PRIMER
• A Migration Primer
• Messaging System Deployment Guide
• Migration Strategy Guide
• Coexistence Strategy Guide
• Migration Process Guide
• Migration Issues Guide


MIGRATION STUFF
• Example Migration Checklist
• Example Migration Jumpstart Guide
• Example Migration Roadmap
• Example Best Practices

RESOURCES

• Open Cranium
• IT Ethics Newsletter
• infonition

Migration Strategy Guide

Introduction

The first step in migrating from a legacy email system to a new email system is to determine an overall migration strategy. While there are nearly an endless variety of specific migration strategies, there are three primary migration strategies from which to choose. These include:

• Light Switch
• Standard
• Dual

Quick Tip: As a general rule, a Light Switch migration strategy is preferred over other migration stratgies because it eliminates coexistence, which adds considerable complexity. However, Light Switch migrations have generally been relegated to small shops due to the speed with which email data can be migrated and/or the simple logistics of dealing with a multi-national email system. Rocket pretty much takes care of the speed issue, the speed at which email migrations could be performed was never a limiting factor in any migration that I performed. I have personally performed Light Switch migrations for organizations of up to 2,000 mailboxes and given a three day weekend would be confident of Rocket's ability to scale to nearly any sized Light Switch migration. The tougher nut to crack is multi-national email systems where one must deal with slow network links and multiple time zones. In addition client deployment can also be a limiting factor, although desktop software deployment tools have come a long way in recent years and may now finally be up to the challenge. Finally, there are a whole host of other organizational and logistical issues to consider with very large Light Switch migrations, such as the bandwith of the Help Desk or the logistics of training.

Light Switch

A light switch migration focuses on achieving a speedy migration of mailboxes to the new system, in effect flipping a switch whereby one day users are utilizing the legacy email system and the next they are utilizing the new email system. Light switch migrations typically do not include any coexistence between the two email systems. Coexistence is not required due to the speed with which email mailboxes are migrated.

Light switch migrations are typically used in small shops of up to about 200-300 mailboxes. The number of mailboxes is a constraint due to the time and effort required to migrate the actual email data contained within the legacy system. Therefore, the light switch strategy can be used in larger environments if email data will not be migrated or if combined with a Dual Migration strategy where the mailboxes are migrated first and the email data is migrated at a later date. And again, Rocket addresses the speed issue but see the other caveats above in the Quick Tip.

Standard

The standard mailbox migration strategy involves migrating legacy mailboxes and their associated email data individually in batches according to a pre-defined schedule. A standard migration necessarily involves a coexistence period where both email systems are considered production.

Dual

An alternative to the light switch and standard migration strategies is the dual migration strategy. The dual migration strategy’s purpose is to shrink the amount of time it takes to perform mailbox migrations during the critical deployment time period by reducing the amount of data that must be migrated during that time. Using this strategy, the Standard migration process is changed considerably such that each mailbox is actually touched twice, once to migrate a limited amount of mailbox data and again to migrate the balance of mailbox data.

To implement a Dual Migration strategy one must choose a retention limit for messages during migration. Typically this is between 0 to 90 days of messages. On the day of migration, anything within this retention limit is considered mailbox data and is migrated as part of the deployment process. Anything that exceeds this retention limit is considered baggage and is migrated external to the deployment process.

The Dual Migration strategy may at first appear inefficient and overly complicated. However, this is the only method of reducing the time frame required for messaging migration during deployment. It can also be an effective means of weaning an organization off of a long message retention limit.

There are actually four separate methods of implementing a Dual Migration strategy with various pros and cons. Those methods are Pre, Post, Public Folder and Archival and refer to when and where the baggage is migrated and stored within the new messaging system.

Pre

The Pre method migrates the baggage before the actual data migration. This scenario is effective if given a long lead-time where servers can be installed and configured but migrations cannot begin due to other deployment considerations.

The biggest issue with the Pre method is that the new mailbox must exist before messages can be migrated into the mailbox. Therefore, this mailbox must somehow be hidden and kept from receiving messages before the actual deployment date for that mailbox. Generally, this can be accomplished fairly easily, except during the actual baggage migration. Usually, within the time frame of the baggage migration it is possible for messages to find their way into the new mailbox. Therefore, it is often required that each mailbox be opened after migration and any mail that has arrived during the baggage migration be forwarded to the legacy mailbox. The advantage of the Pre method is that users start out with all of their messages.

Post

The Post method migrates the baggage after the actual data migration. This scenario is effective if one is unable to deploy the messaging servers before user deployment begins. The biggest disadvantage of the Post method is that the users are without their old mail during the messaging deployment. If a dual migration strategy is being employed, then it is likely that all of the time during deployment is being used for data migration. Obviously then, the Post method works best for deployments that have a short duration. The advantage of the Post method is that there are no concerns over mailboxes being created before actual mailbox deployment.

Public Folder

The public folder method is an interesting spin on the dual migration strategy and confers several benefits. Unfortunately it also adds some complexity. The public folder method places baggage into the public folder system. Each individual user has a public folder specified with security such that each user can only access their individual baggage public folder.

The Public Folder method is designed to allow pre-migration of the baggage without the disadvantages of having mailboxes exist before actual deployment. Therefore, using the public folder method gives the benefits of both the Pre and Post methods without their disadvantages. An additional benefit of the Public Folder method that it is an effective means for weaning users off of an existing, long mail retention period to a shorter retention limit.

However, there are many disadvantages to the public folder method in terms of complexity. First, there is the issue of configuring the initial public folder hierarchy, security and access control. Second is the issue of actually migrating the baggage into the public folder and how automated that process can become. Third is the issue of the effect of this method on the public folder use and design. And finally, there is the issue of user education on the proper use of the baggage in the public folder.

Archival

The archival method refers to the use of third-party or native tools to archive user email data. This can occur either pre or post deployment. This method places baggage into a separate archival system where users can retrieve the information. The main advantage of this method is that the baggage is not transferred into the new messaging system.

Most email clients come with native archival capabilities. The strategy here is to give the users access to their legacy email client by either leaving the legacy email client on their desktop or giving them access to the legacy email client via something like terminal services. The chief disadvantage here is that the user is typically responsible for the archival of their messages. In addition, one must leave the legacy email client around or provide access to it.

There are also a host of third-party email archival tools. The majority of these tools provide access to this information via a web browser and maintain user security. Depending on the tool, archival is either performed on the front-end by the user or the back-end by administrators. The main disadvantage of this method is the cost of the archival tools, which can be considerable. In addition, good archival solutions may not be available for certain legacy email systems.

Contact:  Gregory J. Deckler