Monday February 09 2004

FreeEmailMigrations.com


 

 

WHAT'S NEW

ABOUT

SOFTWARE

DOCUMENTATION

KNOWLEDGE

RESOURCES

 

Migration Process Guide

Introduction

Regardless of the chosen migration and coexistence strategies, the process for actually migrating the email data from the legacy email system to the target email system is essentially the same. This process involves a series of steps that must be completed prior to and after the actual migration of email data.

  • Migration Account – The first step required for migration is to establish a migration account. This account should be created in both NDS and AD, and have the same account name and password. This account is used for all migration process activities.

    • Quick Tip: For EXchange, create a single migration account in AD called something like "migration". If you are migrating from GroupWise and using Rocket, you need to create a migration account in NDS for each GW PO that you will be migrating from. Call these something like "migrationPO" where PO is the name of the PO. Give all of these accounts the same password, something like "migratee2k" for ease.

  • Access – The next step required for migration is to establish proxy access rights for the migration account to every mailbox that will be migrated in GroupWise. This can be done by the end users (See “Appendix A: Instructions for Adding GroupWise Proxy Access”) or by a single, dedicated resource. In the case of a single, dedicated resource, that resource would either need to reset everyone’s passwords or to know everyone’s passwords. Alternatively, a tool such as the GroupWise Bulk Migration Tool can be used to complete this process.
  • Link – The next step is to link NDS and AD user accounts for purposes of email migration. This is accomplished by adding the “GWISE:” proxy address to AD. This proxy address consists of the GroupWise MHS-style email address, Domain.PO.userID. Linking can be accomplished by exporting directory information from GroupWise and importing this information into Exchange. “Appendix B: GroupWise Mailbox Directory Export Fields” contains a list of the typical fields exported from GroupWise. This file can be used to import information into AD using LDIFDE. “Appendix C: How to Use LDIFDE to Modify AD Information” contains the information on how to do this. Alternatively, it may be more cost effective to manually enter this information into AD. There are two concerns with manual entry, time and accuracy.
  • Create Migration Process – A fully detailed and repeatable migration process is the lynchpin in any successful messaging migration. Therefore, the creation and subsequent testing of the migration process is crucial to the success of the email migration.
  • Test Migration Process – Once Migration Account, Access and Link are completed and a migration process is created, test migrations can occur at any time and can be performed without effecting the production messaging system or systems.
  • Pilot – Pilot is the migration of production mailboxes in order to thoroughly test the issues that will be encountered during production migrations. Pilot is typically confined to a small subset of mailboxes with a period of time allowed to go back and improve the migration process.
  • Migration – Once the email migration process is created, thoroughly tested and piloted, the migration process can commence. This process is covered in more detail later in this guide.
  • Legacy Retirement – Once migration is complete, the legacy email system must be retired from service. This includes the removal of legacy client software, the removal of legacy mailboxes, distribution lists, public folders and other legacy messaging objects and services and the retirement of legacy messaging servers.

Migration Process

A fully detailed and repeatable migration process is the lynchpin in any successful messaging migration. This document provides an overview of a migration process based on industry best practices. This overview provides a starting point in the engineering of a more detailed and customized migration process. Detailed migration processes must be developed individually within a specific migration environment in order to account for the unique aspects of that environment. Only by developing and thoroughly testing the migration process within a specific migration environment can reliability and repeatability be obtained. This means that both the legacy and target messaging systems must be well defined and documented prior to the engineering of a detailed migration process. Once the legacy and target messaging systems are documented, the individual processes defined by the migration process flowchart can be engineered and documented in detail.

The two diagrams below, and subsequent explanation, provide a flowchart of a standard email migration process. The specifics of the process will vary depending upon the individual environment in which this migration process is engineered and executed but these diagrams serve as a useful template for creating a reliable and repeatable migration process.

  1. Migration schedule created (weekly)

    2. A migration schedule is created that identifies the users being migrated in particular weeks. A particular week’s schedule is created in advance (Migration Day – (X – x + 1)) weeks. In this equation, X stands for the total number of iterations of the weekly schedule and x stands for the current iteration number. Therefore, the first migration schedule for a migration process with 3 weekly iterations will occur 3 weeks prior to the first day of the scheduled migration week and the last weekly schedule will occur 1 week prior to the first day of the scheduled migration week.

  2. Migration schedule published

    3. This process publishes the migration schedule to the all interested parties. This should include anyone involved in the messaging migration project as well as managers of the users being migrated. Publishing the migration schedule is essential in order to generate feedback on changes to the migration schedule.

  3. User notification

    4. Users should be notified directly of the week that they are scheduled to be migrated in order to generate feedback to the migration schedule.

  4. Training scheduled

    Proper training is essential to the success of any messaging migration process. This process ensures that the training schedule coincides with the messaging migration schedule so that users are trained before they are migrated and so that users are not trained too long in advance of their migration date.

  5. Migration schedule changes

    Changes to the migration schedule can occur in the form of changes between certain weeks or days, dropping users from the migration schedule, adding users to the migration schedule, etc.

  6. Migration schedule created (daily)

    A migration schedule is created that identifies the users being migrated on particular days. A particular day’s schedule is created in advance (Migration Day – (Y – y + 1)) days. In this equation, Y stands for the total number of iterations of the daily schedule and y stands for the current iteration number. Therefore, the first daily migration schedule for a migration process with 3 daily iterations will occur 3 days prior to the first day of the scheduled migration week and the last weekly schedule will occur 1 week prior to the first day of the scheduled migration week.

  7. Migration schedule finalized

    The final migration schedule on a per-day basis is “locked”. This is a significant event since this indicates commitment of specific users to specific dates for migration. From this point on, changes to the migration schedule will result in extra work on the part of the migration team. Therefore, changes to the schedule from this point forward should be challenged to ensure that frivolous schedule change requests do not increase the costs of performing migrations.

  8. Final migration schedule published

    The final publication of the migration schedule should include a note about the policy for migration schedule change requests moving forward and the work involved in processing such requests.

  9. Final user notification

    Users are notified of the specific date that they will be sent to training and the specific date that they will be migrated. Users should also be informed of the policy for migration schedule change requests moving forward and the work involved in processing such requests. Users should also be notified of when to be out of their legacy messaging system and when they will be able to start utilizing their target messaging system.

  10. Training scheduled finalized

    The final training schedule is locked and published.

  11. Pre-migration

    Pre-migration tasks generally occur approximately 12-15 hours before actual data migration occurs. Once these pre-migration tasks occur, it is not an easy process to roll-back. Therefore, schedule changes from this point forward should be handled as emergency requests. It should be well communicated that in the event of a schedule change after pre-migration tasks are complete that any guarantees as to address fidelity and message fidelity are forfeited by the individual whose migration schedule has changed. Roll-back is a best effort process and cannot and should not be guaranteed.

    • 11a. Create target mailboxes

      • The mailboxes and adjunct objects for the day’s users are created on the target messaging system while any external directory objects for those users that point to the legacy messaging are removed from the target messaging system’s directory. This ensures that all new messages generated on the target messaging system flow stay within the target messaging system. This is an important first step in achieving acceptable message and address fidelity during the migration process.

    • 11b. Redirect message flow to target mailboxes

      • This is an extremely individualized task depending on the migration environment. In general, this entails redirecting the directory of any intermediary messaging systems that lie between the target and legacy messaging systems to route messages to the target mailbox versus the legacy mailbox of the users being migrated. Generally, this also involves renaming or hiding the user’s legacy messaging system mailbox and replacing the display of the mailbox with an external mailbox definition that points to the target messaging system. This ensures that all new messages generated in all of the messaging systems are now flowing into the target messaging system mailboxes.

    • 11c. Localize legacy post office(s)

      • This is an optional task and involves creating a copy of the legacy post office to use during conversion. Again, this process is designed to minimize the possibility of messages being lost during the migration process and to minimize the down time for all messaging users. By creating a copy of the post office, the post office can subsequently be brought back up for use while the migration occurs on the copy of the post office. Since all message flow for the migration mailboxes has already been redirected into the target messaging system, no new messages should flow into the legacy mailboxes. In fact, the legacy mailboxes can be removed at this point, although it is more common to keep these mailboxes a few days for disaster recovery purposes.

  12. Execute daily migrations

    13. This process is the actual data migration of a user’s mailbox and is detailed below.

    • 12a. Go/no go decision

      • This is the final go/no decision for migrating a mailbox. If the decision is yes, then the migration process is irrevocable. Rolling back the pre-migration steps for a user is bad enough without also rolling back full data migration. It must be stressed that once this decision is made, either yes or no, that the decision is final and the corresponding processes will be carried out. Failure to do so will result in confusion, wasted time and effort and often a failure in address and message fidelity.

    • 12b. User Training

      • User training often occurs in parallel with data migration. Typically, users should expect to be out of their e-mail system for an entire day (and often 12 hours prior). This is important since scheduling users down to a particular hour or minute is too much overhead for the migration process. Therefore, it is not certain exactly when a particular user will be migrated in the course of a day.

    • 12c. Data migration

      • Actual data migration is obviously a crucial step in the migration process. Data migration may entail moving messages, calendar items, tasks, personal addresses, archives, etc. Exactly what can be migrated is generally a function of the migration tools available between the systems. In addition other considerations may have a factor in terms of what data is migrated. The less data that is migrated, the faster and less expensive a migration. In general migrating archives and personal addresses can add a significant expense to the migration process since these generally exist separate to the messages in the system and are often stored on local hard drives. Therefore, a separate engineering migration process must be created in order to collect these files. In addition, it is generally necessary to utilize separate tools for migrating archives and personal addresses. Calendar items are also often stored outside the messaging system and require separate tools or at the very least a separate step in the migration in order to integrate the calendar items into the target messaging system. The legal department may also wish to use this opportunity to enact limits on how long messages are stored in the system. Therefore, the migration process may need to enforce a policy of only migrating data that is so many days old. Administrators may also wish to enact new policies in terms of mailbox sizes that the migration process will need to account for.

    • 12d. User returns to desktop

      • Once a user returns to their desktop, their migration may or may not be complete depending on how long training is and where they fall within the migration schedule for that day. Since their new mailbox exists, it is possible that they could utilize their new messaging system even though the data migration is not complete. This is a possibility but is generally not practiced since migration tools often require exclusive access to the target mailbox. Upon returning, users should generally receive additional marketing material and quick reference information such as help desk numbers and training reinforcement.

    • 12e. Next user

      • Repeat this process for all scheduled users that migration day.

  13. Redirect message flow to legacy mailbox

    14. This process reverses message flow within the legacy message system and all intermediary systems to flow back into the legacy mailbox. This is the first process in rolling back pre-migration steps for a user. It must be understood and communicated that this is not part of the normal migration process and is an emergency procedure only. Therefore, address fidelity and message fidelity cannot be guaranteed. To get to this point, an extraordinary set of circumstances will have taken place. It is imperative that the bar for forcing a roll-back of the pre-migration steps be kept high and that each request is challenged appropriately. Otherwise, the migration time and cost will spiral out of control.

  14. Forward messages in target mailbox

    15. This process ensures that any messages that have already arrived in the target mailbox are forwarded to the legacy messaging system. These messages will not support full address fidelity.

  15. Delete target mailbox

    16. The target mailbox is deleted and an external recipient is created in the target messaging system that points to the legacy system mailbox. The user is now fully restored to the legacy messaging system. The user can be rescheduled and the process executed once again. It is generally a good idea to move mailboxes that cancel their migration at the last minute to the end of the migration schedule. This is as much for practical reasons as for punishment. Users that have shown such a disregard for the migration effort and have proven to be unreliable should not simply be rescheduled on the next day where they might once again interfere with the migration effort. Instead, it is much more reasonable to schedule these unreliable individuals last where they will have little effect on normal migration operations.

 
Comments:  Gregory J. Deckler
© 2003 Gregory J. Deckler.  All rights reserved

Contact:  Gregory J. Deckler