Email archive migrations bring into play considerations that are unique when compared to any other type of data migration. These concerns dictate that organizations use robust data migration software that is specifically tailored to meet the migration requirements of email archives. In this second installment of my 3-part blog series on email archive migrations, I examine the five (5) specific traits that email archive migration software must possess to successfully and securely move and/or consolidate existing archives into a new email archive.
Trait #1: Advanced Verification
After an email message is moved into an archive and its move is verified, advanced verification calls for a third hash of the message. It asks the source system for the message again, re-hashes it, and then compares that new hash to the original hash already stored in the migrate product and confirms that they are the same for an even deeper level of validation. This provides a legally defensible chain of custody that ensures the migration of an email archive does not impact an organization’s ability to remain compliant.
Trait #2: Hosting and Scripting
A major concern for any migration project is the requirement to procure additional infrastructure to perform the actual migration. This may hinder a migration effort as this new infrastructure may only be required for the migration itself and serve no other purpose.
In some cases, organizations look to use older hardware (servers, networking and storage) to mitigate the cost associated with acquiring new infrastructure. The concern with using older hardware is that it will not perform and/or it will not be as stable as the migration project requires.
To mitigate this concern, ideally the software provider will host the entire migration infrastructure. This minimizes or even eliminates the need for organizations to acquire new hardware, install it, and then configure the software on it. Further, the software provider should also supply the needed scripts that integrate with the existing email archiving software to simplify and monitor the migration.
Trait #3: Forecasting
A challenge in any migration project is forecasting its completion timeline. No email archive migration is exactly alike, with each one accompanied by its own set of stringent (and sometimes seemingly impossible to meet) management expectations as to when an email migration project will be complete. Aggravating the situation, every email archive migration seems to inevitably encounter performance bottlenecks that stem from using either out-of-date production hardware or software that further exacerbate the difficulty to forecast a realistic project completion date.
To mitigate this issue, the software should first gather information about the environment, analyze it and then identify key areas where problems are likely to surface. By using this aggregate set of analysis and information, it should then be able to produce a realistic forecast for when a migration project should be completed. This forecast will account for the obstacles that will be encountered and the time it takes to overcome them.
Trait #4: Journal and User Migration Options
Journal and user migrations are the two general migration types that organizations may need and which the software should accommodate by addressing the specific set of challenges associated with each migration type.
- Journal migration. Every email archiving product (as opposed to an email archive migration product) has the challenge of preserving the context and format of a “Sent” message to ensure all compliance requirements are met. This requires that it capture all metadata associated with the message. While it may capture obvious recipient information such as those names in the “To” and “CC” fields, it also must capture and retain “BCC” recipients as well as the names that were part of specific distribution lists at specific dates and times. Referred to as envelope journaling, this information must be captured and preserved so a complete and accurate picture is created of who actually got a copy of the message.
The concerns around journal archiving as it relates to migrations are two-fold. First, email archive software products keep pulling messages from the journal mailbox. Once captured in the archive, the message(s) are deleted from the journal along with the envelope information. Second, the email archive migration software must migrate all of the metadata associated with each message’s envelope to preserve chain of custody.
- User migration. A user migration is employed when no compliance requirements have to be satisfied during a migration. While this removes some of the concerns associated with journal migrations, most email archive software platforms use some form of shortcut (stubbing) that links to archived messages from within user mailboxes.
These links usually appear as regular messages to the user. However when their email client goes to access the data, it pulls the message from the archive system as opposed to the email server. As most organizations expect minimal to no end-user disruption during an email archive migration, it is critical that the email archive migration software preserve and update the functionality of these shortcuts during the migration.
Trait #5: Migration Management and Monitoring
Organizations may spend a lot of time preparing for an email archive migration, but once the migration starts, the real work of managing and monitoring the migration begins. On the hardware side, migrations may need to be accelerated, slowed or even stopped depending on changes in the production environment itself. Other factors such as server, networking or storage hardware failing may result in unexpected halts in the migration from which the software needs to be prepared to recover. Unforeseen bottlenecks in the infrastructure that preclude the migration from taking place as quickly as planned may occur.
The email archive migration should detect these events and generate alerts that the process has slowed, been interrupted or even ceased to function. Should a migration stop due to some type of failure, the software should regularly create recovery checkpoints so the migration may restart and resume from the last known checkpoint.
The software must also look beyond the hardware and point towards the data itself to verify that its integrity has been preserved during the entirety of the migration process. It should provide hashing or fingerprinting to validate one-to-one mappings of the data as it is moved from the source to the target, as this is an important component of preserving and proving chain of custody. Then, as the software moves this data, it creates an audit trail by logging the data that was moved, when it was moved and how it was moved.
In part 1 of this 3-part blog series, I examined the unique demands of email archive migrations.
In part 3 of this 3-part blog series, I will discuss why GlobaNet Migrate is the best way to do next generation email archive migrations.