Legal data migration in ediscovery can seem overwhelming, but a proper plan will keep the process simple. Here’s what you should keep in mind when moving data to a new ediscovery platform.

Change is inevitable, and that adage holds true in ediscovery. There are times when it becomes necessary to move a review database to a different provider or platform due to additional feature needs, increasing costs, or other complications. It sounds like an easy task to tackle, but there are several critical “gotchas” you need to consider before moving forward with a legal data migration project.

Migrating data sounds like it’s the purview of IT professionals (and it is, mostly), but the decision to migrate legal data in the context of ediscovery is often driven by business or expense reasons. Perhaps your litigation matter has transitioned to a phase where you don’t need the same set of features you once did and can switch to a different platform. Or perhaps the expense of hosting your terabytes of data has become cost-prohibitive, and you can save some money by migrating the database to another platform.

Legal professionals must also be involved with key decisions throughout the migration, such as determining which data to transfer, whether to archive or delete any data, and which associated work product should be included in the migration. If you don’t take an active role in overseeing key factors of the migration, you risk losing essential components of the data, like important metadata fields or notes and coding.

While legal data migration sounds like a simple task of just copying files, there are levels of complexity involved that require a well-planned approach. Additionally, data migration in ediscovery carries a heightened importance because we have to maintain a defensible documented record of where electronic evidence is stored, organized, and maintained.

Here are some key considerations to keep in mind to ensure your legal data migration project goes smoothly.

Don’t Be Shy: Ask for Help

The most prudent advice for legal data migrations: Don’t try this on your own! Most folks will ignore this astute advice, but your time is valuable, and you certainly don’t have time to redo work or correct negligent mistakes. Data migration in ediscovery is actually very technical and requires a comfortable working knowledge of esoteric terms and database structures. Sure, you can try to learn all that – but the time you spend practicing law might just get in the way.

First, overseeing a successful ediscovery data migration requires working with file formats that can handle large lists of data and references. The individual needs to understand how databases are structured including rows, columns, and delimiters. Next, data migrations in ediscovery involve several aspects of file conversion, which requires a certain comfort level with file compression tools and formats (e.g. zip files, rar, etc.).

Finally, it’s absolutely crucial that one can maneuver through the ancient but ubiquitous “load file” and understand how individual files are organized and referenced. While the formats are not specific to the legal world, there are several proprietary quirks that can only be learned from working with ediscovery platforms.

★ Legal Tech Tip: When choosing a new ediscovery software platform, look for a provider that offers expert ediscovery services to assist with your migration.

Planning is Essential

If you fail to plan, then you plan to fail – it’s no different when it comes to a data migration project. Except the failure here can result in lost time, unwelcome costs, and potential spoliation claims. But the good news is that you can minimize the risks and maximize the success by crafting a project plan that everyone can reference and track.

A data migration plan can certainly include a step-by-step workflow, but it’s also a place where all the information about the project can be maintained and referenced throughout the project lifecycle. For example, here are several items that will help the team make the necessary and proper decisions during the project:

• Where is the data currently being stored and where is it ultimately going?
• What data must be transferred, and what can be archived or deleted?
• What data components need to be migrated? This includes both the inherent metadata properties of the files, as well as subjective notes and tags that may have been added.
• Are there any data components that do NOT need to be migrated?
• What is the expected timeline for migration? And what active matters may be impacted by the migration?
• Are there any files locked with passwords or other security protections that need to be migrated?
• Is there any sensitive or confidential information that needs to be handled in a separate manner?
• Has all the data been through key filtering and processing strategies, like deNISTing, deduplication, and email threading? If not, should we apply these techniques upon import?

A vital piece of this plan is an inventory of all the data that needs to be migrated. This inventory ensures that nothing is overlooked and informs the team on necessary resources, time, and costs for the project. It also helps the team make logistical decisions on the progress of the migration.

For example, is the amount of data to be migrated so voluminous that it makes sense to split the data into smaller sets that could be more easily exported and imported? Are there certain categories or groups of data that are a higher priority for migrating? This can be an excellent opportunity to clean up or dispose of old data that is no longer needed and simply clogging up review databases.

The time spent crafting the plan and inventory will also help identify the best format for exporting data so that there is no data loss or confusion on the import side.

How to Deal with the ‘Gotchas’

In developing the data inventory, you will inevitably come across unique items in the database that require specialized attention. These are usually “work product” components added by the review team that include annotations, redactions, tags, folders, saved searches, attorneys’ notes, and more.

The potential concern is that different platforms accommodate this information in different ways, and attempting to migrate these fields without adequate planning could result in data loss. And since most annotations and attorney notes are put there for a specific reason, we certainly want to minimize any issues or complications.

Best case scenario, the data inventory identifies all the components to be migrated and everything gets matched up properly. Worst case is that critical information doesn’t get moved and could be irreparably damaged. In the middle of that spectrum are instances where certain fields or components may need to be manually exported and handled. Proper planning helps the team move toward the best case scenario.

One last consideration is whether the litigation team needs to migrate previous productions. The answer is typically yes, and this requires some additional planning to ensure numbering schemes are kept intact and the formats are preserved.

Keep Up with Careful Quality Checks

Once you start importing data into the new platform, it’s important to run quality tests to ensure the data and all components are migrating successfully. You can even run test samples before kicking off the project if you identify potential difficulties in the planning stages.

Performing quality checks can include some quick random tests on data, but it should also involve deeper-level examinations to ensure all file metadata, as well as integral work product, is fully accessible in the new platform. These quality checks are typically performed during and after the migration process.

Data Migration Checklist

1. Find ediscovery experts who can help you structure and execute your migration
2. Determine which data will be transferred and which (if any) will be archived or deleted
3. Decide which components of the data should be migrated, such as metadata fields and work product (notes, coding, etc.)
4. Consider dividing your data into groups to perform a segmented migration
5. Develop a plan for performing quality checks
6. Outline the technical specs for your data migration project. What file format(s) will you use to export the data? Will your chosen format(s) translate well to the import stage? Will you use a third party tool to simplify the process, like Universal Migrator? Focus on utilizing formats and tools that will minimize processing time while maintaining the integrity of the data.

Don’t Be Afraid of Legal Data Migration

All these considerations may have you thinking that you’re better off sticking with your current technology – even if it’s outdated, cost-prohibitive, or simply not meeting your firm’s needs. But data migration can be simple with the right tools and expertise. For example, this story explains how Foley & Mansfield, a national firm based in Minneapolis, successfully completed a major data migration project and increased user adoption of their software by 20%.

Data migration also presents a valuable opportunity to reset, audit your data, clean up your storage systems, archive what’s no longer relevant, and take note of what you still have access to. Starting fresh with a better software solution is well worth the minor technical challenges that come with a data migration project.