In part one of this discussion, we covered the source and the destination infrastructures for the migration project. With the full understanding of the source’s limitations and how the destination will affect the outcome, the migration infrastructure development and migration planning can proceed.

PART 2 The Infrastructure

The infrastructure for the migration is where the migration toolset would be installed. All of the migration tools are available for an installation on premise and will call for a fairly significant infrastructure to be provisioned. These installations will call for at least one migration server and a SQL database to manage the operations. In the new world of migration tools, some have embraced the cloud to eliminate the onsite hardware requirements and allow for a quicker inception to the migration project. For a cloud migration to be effective, the client must have an ample pipeline to the Internet or else that connection will become the bottleneck and would reduce the overall efficacy of the migration. When migrating to any cloud based service the Internet connection will also be a common bottleneck and can as with the cloud servers limit the migration’s overall throughput. The biggest consideration with the migration is unfortunately one that will be difficult to predict. That is the rate at which the migration can move data. Some solutions indicate that by provisioning multiple migration servers in an effort to increase this throughput although this often works, this will increase the migration costs; and where exactly the tradeoff between the cost and speed is not easily determined.

The bottom line is that until the data starts to flow and measurements can be taken, estimates are all that are available and the buyer needs to beware of all claims of expected throughput. Just like buying a car, ”your mileage may vary”.

The Planning

The planning begins With the source, destination and infrastructure decisions made, one might think that the best plan for the project is to migrate the email first and then approach the archive. However this is not always the best approach for the users. The more successful migration projects are those in which the users are impacted the least and the most successful projects are when the user did not even notice the project had taken place. A word of caution is that these levels of impact can have a dramatic effect on the overall costs and timeframes of the migrations. Many factors to include in this decision point revolve around the user and the email in their mailboxes. The graphic below represents the typical migration project. The migration effectively has manage the 3 axis points. The User Experience, Migration Expense and the Time required to perform the migration. Minimizing any one of these will cause the other two to effectively increase. This balancing is key to the overall migration.

With the variety of archive solutions currently in the marketplace, many will have removed email from the mailbox and the only access to this data is via search mechanisms or shortcuts left in the mailbox. This issue is best managed in one of 3 migration approaches 1. Coupled 2. Semi-Coupled 3. Decoupled

These migration approach factors in the table below will have to be weighed by the organization to determine the level of cost of the migration compared to the level of end user impact to determine the appropriate course of action for the migration project.

Before Production Migration Begins

So with the basic plan worked out as to the migration process, the next step should be to proceed into small scale testing of the migration. It is most common that during these tests that there will be some unexpected results. These results when properly addressed will go a long way to ensure a much smoother process when the full migration has begun. This testing should use representative mailboxes of various sized and complexities to ensure a valid output. This testing will provide a baseline of the overall migration rates and throughput from Source to Target and take all of the infrastructure into consideration. When the testing is completed the expected migration timeline can be extrapolated. Beware that this is still only an estimate and can be misleading if the testing did not replicate the “real world” sample sets. It would be a normal expectation for the small scale testing to take several weeks to complete before the real heavy lifting of the migration even begins to happen.

With the planning and testing completed, a thorough review of the test results must be performed. Review the migrated test mailboxes for accuracy and effectiveness of the processing. Failure to notice a small discrepancy may extend the project and impose dramatic costs when it is realized that a systematic failure was not noticed until most of the mailboxes have been processed. It may be necessary to perform multiple test runs to work out these issues. These reviews should be performed by many different groups within the organization besides IT. Legal, compliance, and executive representatives should be consulted to ensure that the results will hold up to the scrutiny. Only after all of the key players in the teams have signed off on the process should any attempt of a production migration be attempted.

Conclusion

The email and email archive migration project is not a difficult process when all of the parameters of the project are properly managed. However, when the level of planning does not take many of these previously covered items into consideration, the project may simply not achieve the desired level of success. A technically successful migration where all of the archive email has been migrated from the source to the target may not be a business success when the users upset and arming themselves with pitchforks and torches while burning the administrators in effigy. Understanding all of the minute implications these factors play in this process is crucial to mitigating these undue stresses on the business and personnel tasked with growing the company.

-Kevin Thacker (author) Compliance IT Solutions