Let’s say you’re moving, or about to move, firms, or maybe even starting your own practice. But your cases don’t stop just because your office is changing venues and many of those cases involve eDiscovery. So how do you cleanly, efficiently, and effectively move your cases with you? It’s not as easy as copying and pasting (although we certainly wish it was). But here are some considerations and suggestions about making the big move.
Anatomy of the Change
If you’re staying with the same platform but moving the data from one hosting location to another, the software provider might be able to provide workflows or support for the move. In fact, you may be able to do the work yourself or utilize the support contract with the receiving host. Considerations for this type of change would be whether the current and future software versions are the same, whether the hosting venue is different (on-premises vs. the cloud), use of the same username structure and whether a similar set of features of the tool are activated.
If you’re switching platforms, it’s advisable to consult an expert because there can be nuances to the way each tool stores information (particularly with coding). Moving from desktop-driven platforms to modern web-enabled platforms is another time to consider asking for help, as information may not be easy to export.
Databases, Having a Chat
Although it seems like it should be simple, moving a database from one platform to another can require some expertise. In fact, sometimes just moving data from one project to another within the same platform can be challenging. The are specificities about the way eDiscovery tools catalog data, and the use of fields, although it can be similar between two tools, is not standard across all of eDiscovery. For instance, fields may contain similar data but be named differently. This requires intervention by a knowledgeable eDiscovery person to match those fields to ensure the integrity of the information is maintained.
The most common way to move data between platforms is to export the data in a loadfile with all fields (as a .DAT file) along with the natives, redacted images, and coding. eDiscovery tools are designed to load those .DAT files and natives easily – the difficulties come from getting the coding, redactions and productions loaded.
Logging and document history is another consideration when it comes to moving eDiscovery cases. What actions users took, who created a redaction, and who ran a production can be important to a case. Although most tools allow the user history information to be put into a spreadsheet, it is not advisable to load that information to a new tool. Usernames can be different, the implementation of user history may not be similar, and those logs should be treated more like a static record of what happened.
Search term reports may not translate during a database move and may be hard to redo because search syntax is not standard across the industry. There are two primary search engines – DT Search and elastic search – and in most cases their syntax is vastly different. So take note of which search engine is used both in the previous tool and the future one in your case.
Preserve Your Work
It’s likely you’ve made productions, done coding, and created comments in a way that you want to keep when you switch tools or firms. You’ve already paid for this to be processed and loaded once, and you certainly don’t want to pay to do so again for a new tool. Modern eDiscovery tools will let you load loadfile data with native information and re process those natives in place (building in empty metadata if a previous tool didn’t extract it).
But eDiscovery tools are generally not designed for importing and exporting coding and redactions partially because there is no standard form across the industry for how redactions are implemented. At the highest level, some redactions are permanent to an image (like with Adobe) but modern review tools allow redactions to be edited, moved and deleted. There is no standard framework for how a redaction is applied to a document across platforms. Indeed, even within a platform, moving a redaction from one project to another is risky because in the new project the image may be re rendered and the location of a redaction may not be the same in the re-rendered image (it may be covering up something different). There is also a risk to re-processing data in a new platform, because it may extract different text or that text could render differently. This could potentially lead to a desire to re-review all the data, at great cost and time expended.
The solution is to move the redacted and unredacted version of the images separately and store them in the new tool. This can be accomplished using two standard productions, which is something most typical eDiscovery tools and users can do.
The use of artificial intelligence in eDiscovery tools is increasing dramatically, and it’s important to consider that any work done within a tool using AI might not translate to a new platform.
Timing
Given the need for expertise in migrating data, the process of moving a case isn’t always immediate. In fact, it may take some time. Having a cutover date in mind for when the firm move or new office opening is complete is a good idea, and communicating that to your information technology personnel and your eDiscovery and litigation support experts is very important. They may need extra time during the night or weekends to make things work, so ask them about their needs ahead of time as well. If there’s a case that is going to trial or has important upcoming dates, consider either leaving that case in the old tool or moving it first.
There are two time components in a move like this: human time and computer time. The human time is driven principally by the complexity of the project but not by the number of documents or gigabyte size. For instance, a project with thirty individual productions where documents are produced more than once is more complicated than a project with thirty productions that contain non-duplicative documents.
Computer time during a move can be quite significant, and it is based on the number of records and size of data. Note that computer time is comprised of four categories: the time to export, the time to download and upload into the new tool, the time for conversion of data if necessary, and the time to import into the new tool.
Conclusion
Productions can be used to move most data, utilizing the import and export features of eDiscovery tools. In some cases this can be done in a self-service environment without having to pay for gigabytes or support time. Difficulties lie in moving substantive coding so it looks similar from one tool to another, handling redactions, and maintaining user history. Re-paying for loading data, coding, and review is a concern but can be avoided with the use of experts if the situation warrants. In general, if you move from one review platform to another the costs should go down and the features should go up given the movements and improvements in the market.
[View source.]
