Exterro's Legal GRC Breakdown

Get your daily dose of news, best practices, and technology from Exterro's e-discovery, privacy, and digital forensics experts here.


E-Discovery Data Migration: Mitigating Risks and Achieving Success

Created on March 27, 2012

By David Hartmann, Director of Client Success, Exterro

When companies deploy new e-discovery technologies, introducing existing data from legacy systems is usually among the primary implementation challenges.  Data “migration" is a reality of the technology world that extends far beyond the realms of e-discovery systems. Yet, e-discovery presents unique risks, since lost or altered data can lead to serious legal consequences.

Why do companies move data in the first place? The amount of electronic data that large corporations produce is staggering and growing exponentially. To fully realize the benefits of their technology investments it is essential that organizations move - or migrate - older data to the new systems. There is also significant value in centralizing data across the enterprise. Organizations with data scattered among disparate systems leave themselves exposed to serious risk and often struggle to manage e-discovery projects. However, these data migrations can be problematic if they aren't carefully planned and thoughtfully executed.

The data migration process is largely dictated by the specific applications involved. Every project presents its own unique set of requirements. Fortunately, there are simple steps every organization can take to help increase the likelihood of a successful migration.


Before the actual movement of data between systems, it's important for organizations to evaluate the key objectives of the migration from both a business and technical perspective. This involves a careful consideration of the data itself: what must be transferred, what can be discarded, where are problems likely to arise, etc. It's imperative that the parameters of the migration process be carefully defined and that a plan be devised that incorporates timelines, quality controls and risk mitigation.

Depending on the source system, migrations will sometimes need to be handled incrementally or in fragments, and those fragments will ultimately need to be stitched together. Organizations must consider resource requirements, namely who is going to be responsible for the work and what will they need to complete the task successfully. The final point of closure for the evaluation step is success criteria: what will a successful migration look like and how will that success be defined. Answers to these questions should be documented and revisited for final validation of the migration project.


When it comes to actually extracting data from an outmoded tool or legacy system, accuracy should be the number one priority. A complete internal validation of the data set is required to confirm that it will be compatible with the target system requirements. This involves a full evaluation of the data source types, field names, the structured order of the data being mapped, the integrity of the historical record and the formatting of the source data files. In those tricky situations where the process is being stitched together, the entire set of components listed above must be accounted for and confirmed against the requirements of the target system. While the design of the extraction is important, ultimate success rests on the export itself. Organizations need a quantifiable way to measure whether all the data exported properly. Sampling can be effective; but a more comprehensive data point confirmation of each record is the only full proof way to validate the extraction.  Upon a successful export validation the ingestion process can begin.

Data Ingestion

Ingestion - the importation of data into the new system - is a multi-part effort. First, the source data needs final validation against the target system requirements using a sample set of data to test the ingestion.  Questions to consider at this stage include:

  • Do the source data points map to the new environment as expected during the evaluation effort?
  • Does the type of data from the original source match the data types of the new system in design and function?

Should the test prove successful, then the migration team can proceed with the actual ingestion. This process should begin with a backup of the target data environment as a fail-safe in case something goes wrong. The whole process should be monitored live to ensure any problems are dealt with promptly.

Final Validation

The final validation of the system requires both a technical and business sign-off. By revisiting the success criteria set forth at the beginning of the project, the business and technical teams need to do a final evaluation before the system is accepted to “go live." The sponsors of the migration need to accept the final result of the migration and be prepared to cease operational practices that would cause old systems to generate new data. In cases where both the old and the new systems stay operational post migration, the project team will need to determine if future migrations are required and if so how the process can be refined going forward.