This blog was co-authored by Peter Coons, Co-Founder and Chief Client Officer. 

Migrating from one litigation support application to another requires careful thought and planning. Whether the application you are migrating from may have a migration plug-in or other built in migration module, the process should always entail a well-defined and thought through plan around the requirements for migrating your data repositories as well as for the execution and validation processes.

Planning Your Data Migration to a New Document Review Tool

A good project plan involves a number of steps that will facilitate efficiencies and accuracy of the process.

1. Create and Prioritize Your Database Inventory

The first step is to create a database inventory. The team would identify and inventory the entire set of databases. The second step would be to prioritize that list. For example, if one database has been dormant for a year, but is still technically active, it may be the first to be migrated. However, a database with active review may have to involve more planning and be done on off hours or in sections. 

D4 can take your data from ingestion through production faster and more seamlessly, using the latest version of Relativity at an unbeatable price. Check out D4 AIR (All-in-Relativity) here!

Whether it’s due to completion or other reasons, not all databases will need attention. Taking the time to prioritize ensures you are spending time and money on migration-worthy databases.

2. Identify Components that will be Migrated 

After the databases have been identified and prioritized the next steps would be to inventory each component that will be migrated. Components should include:

  • Database name
  • Record count
  • Field list to include the types and content
  • Image count
  • Native count
  • OCR counts
  • Productions
  • Transcripts
  • Issue coding
  • Exhibits
  • Tags
  • Folders
  • Saved Searches – this might need to be regenerated so identified those which are required to be recreated in the new system
  • Search term or persistent highlights
  • Other work product that is not discovery loaded to the database
  • User/group access and security requirements

The time spent up front is necessary to provide the team with a clear map to validate that each step has been completed and the resulting migrated databases are accurate. Each component should be listed as part of the migration process and to provide for QC processes for the migrated databases.

3. Manage Annotations and Redactions 

Annotations and redactions made to images within one review system are generally the most challenging for migration purposes.  It is important to determine if the existing system as well as the new system can both provide and ingest some type of annotation references. If not, then alternative workflows must be identified to capture the existing workproduct and carefully factored into the migration planning effort.

Execution of Your Project Plan

The execution process should always follow the project plan to ensure success.

4. Export in Priority Order

The first part is to fully export the identified components for each database in the priority order and timeframe outlined. After the exporting each component the counts should be matched against the data map to ensure that everything has successfully completed.

5. Handling Traditional Export Items

Often times, while the export process seems to be successful, relying on the application to identify errors can prove problematic. The export process from an application often will take care of the typical data items such as the metadata, images, natives, text.

Record Export

  • Export all the results and all fields from the legacy system
  • Validate the results to the data map to ensure that all record counts, field information and tag information have been exported.

Image Export

  • Export Image load file into an acceptable load file format such as an OPT file
  • Validate that all image pointers have exported and match up to the record counts and mapped results

Native Export

  • If the record export did not provide for a link field to native records then there are two options:
    • Locate the original load files and isolate the native file to document number information and create an image load file or annotate an image link field to the record export file.
    • If original load files are not available manually create a link file with the record number and the relevant native file link information.

6. Manage Non-Traditional Export Items

For those, non-traditional, export items such as annotations, highlight sets, transcripts or other more unique components, these will need to be exported either individually or by capturing the information in order to replicate in the new application.

Tags, Folders, Saved Searches

  • Tags and folders or other document flags will often export as a field or individual fields as part of the full data export process identified in Execution Step 1 above.
  • Review the export file and determine if the tags and any folders or other references have been captured.
  • Tags can be created through the use of an LFP load file (as long as the LFP format is acceptable as a load file format in the new system):
  • Saved searches that are needed in the new system should be recorded for re-creation in the new system

Search Term/Persistent Highlights

  • Identify the search terms that were used to create persistent highlights.
  • Create a text file of the search terms used and any categories i.e. relevant, privileged etc. for re-loading

Productions

  • If productions were generated through the legacy system the following should be validated:
    • Production numbers that reference the production records
    • Production link file that will link into the new application
  • Productions that were created and loaded as new documents should be matched to the original record and load files generated that will allow for production documents to be linked to the original record.

7. Quality Control the New Database

Once all the export files and information have been generated and validated, the process to recreate into the new system will require that the creation, loading and validation process is compared to the data map. It is critically important to also factor in time to fully QC the new database. The success of the loading process does not always mean that the database is fully functional. Time should be spent to ensure that the data records will actually pull the relevant native files and images, where applicable. That the database is fully searchable and all the other components such as annotations, highlights etc., have successfully made it into the new environment.

Final thoughts

It is important to plan time accordingly – migration takes time to carefully plan and execute. Prepare for training needs for users and administrators depending on the new platform environment.