Migrating eDiscovery Vendors, Even in the Worst of Times

You are in the midst of a massive discovery project, but you are not getting the performance you were expecting from your legal services provider (ALSP). All you want to do is end the project and the relationship, but that process feels daunting. Do not be afraid. You are not a hostage within your ALSP’s datacenter. There are ways to divorce amicably and move on successfully. In this article we provide a guide for when and how to migrate eDiscovery vendors.

1 - Are You Sure You Need to Part Ways?

You spent a year in an RFP process to identify an alternative legal services provider (ALSP) for your eDiscovery and document review needs.  You reviewed numerous responses, conducted security assessments, interviewed references, completed due diligence and ultimately negotiated a master services agreement.

After a few months, you began to receive questions and concerns from outside counsel about the quality of work and missed deadlines.  You held discussions with your partner to eliminate bottlenecks and set expectations, but the problems did not seem to get resolved.

Then, the perfect storm arrives – a series of government investigations and a massive multi-district litigation that will negatively impact your business and its bottom line.  It is an all-out battle.  You find yourself also having to battle performance and expectations with your partner.

Finally, the previous problems have now been exacerbated.  Poor quality has led to mistakes in custodian identification and tracking.  Inefficiencies in production processes contribute to missed deadlines and threats from opposing counsel for motions to the Court.  You begin to see your ALSP as an adversary rather than a partner.

You deserve better.

2 - Plan Your Exit

The decision to move your eDiscovery work midstream from one provider to another is difficult and can induce a lot of anxiety.  Begin by gathering the answers to the most basic questions about the matters:

  • What does the review and production schedule look like?
  • Are there additional custodians to collect from?
  • What does the deposition schedule look like?
  • What discovery deadlines are looming? When is discovery scheduled to close? 
  • Are cases on a trial calendar?

Then, collect information and metrics related to your data:

  • How much data is hosted by the ALSP and in what environments (e.g. Nuix, Ipro, Relativity, etc.)?
  • What is the volume of the original source/collected data? Who has the collection logs, chain of custody documents or physical media?
  • How many users do I need to inform and redirect?
  • Identify custom workflows and any proprietary applications or technology used by the existing ALSP that may not migrate.
  • What is the volume of existing production volumes? Make sure that all associated passwords are tracked.
  • Are you getting regular reporting that is documented on a regular basis? If not, start considering that now and ask for full reports for all of the above. Ask for dates for various stages so you know where everything lives, who is in control of it, and timelines for activity of the data.

3 - Selecting a New Partner

When selecting a new provider, not only are you looking to hit your previous requirements, now you should identify a partner who has proven experience with data migrations and has the resources to do it. Answers to the planning questions will be critical in scoping a new agreement, migration schedule and scale of the new environment. 

Get to know THE data person(s) at your new ALSP.  The sales and operations managers should steer you in a good general direction, but the technical resource(s) that will be in the driver’s seat for most of the migration should be familiar with you and willing to communicate with details.  You will need to be in a position to make quick decisions.  You will want to hear the problems early and go straight to the source to provide answers. Its also good to make sure you have a good rapport with the person you will be interacting with the most so it will be important for you to evaluate how they are with communication, follow up, documentation, summary of discussions, etc. This is often key to a successful migration, especially since there are often a lot of moving parts when migrating to a new provider.

The new provider will need to begin scaling for the project and right-sizing the environment.  Orders may need to be placed for additional infrastructure, increases to software licensing or subscriptions, acquiring hardware for the migration, and putting the right project management team in place. 

As the environment is being prepared and deployed, timelines need to be established for which databases and data sources to migrate.  The more data sources and a higher demand for access to the databases will complicate the schedule, but the migration can be planned in stages.

Once the pieces are in place, negotiate the termination and exit with the existing ALSP.  Require provider to provider communications between the technical teams, but keep conversations related to the business relationship maintained separate and apart.  Allow the technical teams to consult with one another and develop a migration plan that is acceptable to everyone involved.  There will be hurdles, from each provider’s technology and infrastructure, to security, to the method of transfer, and the availability of resources.

Contrary to a manual crawl, spidering is automated and may discover unclicked links. For the best results, spidering should also be done using a logged-in account. Yet, even by visiting each link, cybersecurity engineers and the web application testing software are limited to uncovering pages that the site links to directly. To further expand the discovery of site content during the web application security test requires forced browsing.

4 - Calling the Movers

Packaging and moving the data, users and processes is crucial as nothing can be left behind.  Use your planning as your inventory, and keep your providers moving concurrently.  Have enough help allocated on both sides to manage multiple channels of information exchange.

Start simple with an easy win for everybody. Migrate users and groups ahead of data migration. The technical teams of the two providers should quickly find common ground with an easy task and establish a sensible rapport with one another.  To avoid a combative interaction, resolve conflicts quickly and document the agreements.  You are still the customer.  Since some eDiscovery work will likely continue while moving between the providers, be sure to follow up with a final user report immediately before migration end to true-up any late user changes.

Before any migration fatigue sets in, tackle the data transfer.  Identify an acceptable and agreed upon method for copying and transferring the data.  There are so many options, and be ready to use them all. A multiple solution approach dependent upon the data volume and timelines is best.

Under some migration circumstances, such as the acquisition of one provider by another, a direct connection and sync-line can be established between data centers. This is ideal for moving large amounts of data, but the biggest detractor is it usually takes weeks to months to set up with a provider.  Also, when a client directs a move from one provider to another, neither will likely agree to such a transfer mechanism for obvious security reasons. Otherwise, encrypted hardware is acceptable for larger packages.  This can include both external drives or portable SAN devices. Transfers utilizing a cloud or secure FTP solution can be appropriate for smaller packages. 

If Relativity workspaces need to be moved, there are several criteria for determining a method of migration – either a full ARM (which includes native files and images) or an ARM of the data only (tables and indexes) while coping the associated images and natives in a separate job.  The full ARM is best for smaller matters and matters that can afford to be offline for two to five days.  The data only ARM and separate file copy is best for very large matters or very active matters that cannot afford any significant downtime.  This method of migration will likely require a true-up of images and natives that can be copied during the ARM and transfer period.  This method will also require logging/auditing of those files to confirm and validate all files have moved.

Antivirus, antivirus, antivirus!!! Consider an exchange of reports identifying files removed by the first ALSP and any additional files removed by the new ALSP which could explain differences during transfer.  This could eliminate or reduce any finger pointing or investigative delays.

Test the process. Take a database that does not have immediate demand and run through the migration, measuring time and throughput.  This will allow some degree of forecasting downtime and setting expectations.  Additionally, technical teams may be able to adjust the scaling of the environment and its bandwidth to increase throughput.

Whatever approaches are agreed upon and executed, contingency plans are a must.  There will be file corruption issues.  There will be missing files.  There will be delays with overnight delivery.  Getting back on your feet and running at operational capacity is of more value to you than the cost of being over cautious.

Transfer of knowledge, documentation and process should be addressed. This is such a significant component to the migration, it is difficult to mention it last.  With the data in hand, your new provider should be able to hit the ground running.  Try to get process maps and workflow diagrams from your old provider to your new provider early in the migration.  Hidden scripts or custom data manipulations are commonly forgotten.  Also, remember that the migration is not a single, linear transfer of information, so keep information flowing in multiple channels.

These lists can be extensive and, based on their size, can significantly increase the time needed for penetration testing. The benefit, however, is a far more thorough web application penetration test.

5 - Managing the Exit Process

Communicate with end-users early and often. Keep them in the loop by way of deadlines, downtime, and expectations.  During any planned outages (when data is inaccessible to end-users), keep key stakeholders apprised of the status and transfer. 

Track everything from data, to package, to hardware, to shipping, to receipt, etc. 

Plan resources. Have people alerted and positioned for the receipt of media and or electronic transfers.  Everything that comes in the door should have chain of custody or documentation confirming the deliverables, including log files of the data transferred and/or copied to media.  This will be essential for file validation.

Restoration processes should also include contingency plans to cover worst case scenarios, the need to revert.  Again, the end-users have expectations of being live at a certain point in time.  They have work to do and deadlines to meet.  Keep your community informed… they are just as anxious as everyone else.

When finished, be sure to pause to celebrate the win.

Closing Thoughts

When deciding to move your hosted eDiscovery from one provider to another, it’s not something you just jump into.  There will always be a risk.  At the same time, do not feel held hostage waiting until the time is right. For most matters, the time will never be right.

Don’t do it alone. When the risks of staying with a provider add to an already difficult litigation landscape, it is important to make a very strategic and calculated plan with a new partner who understands the pain and jumps into the trenches with you.  You need an ally with experience that has done this before, has a defensible process plan in place as well as a battle plan that accounts for the risk everyone is about to undertake.

*Allan Crawford was the original author of this article. Sadly, he passed away in November of 2021 before he completed it, but his TCDI family helped finalize what he had started. Allan impacted so many areas of the industry throughout his 25 year career, but migrations from other vendors was one of his fortes at TCDI. He was a calming presence in what could be highly stressful, time sensitive situations and he was an instrumental part of TCDI’s largest migrations from vendors and acquisitions. Allan’s work and contributions on various migrations were not just great examples of “what to do”, but his professionalism and lightheartedness showed us all how to manage and treat the teams involved in all sides of the process. While TCDI and clients gained new data, hardware and environments, Allan added to his extensive list of colleagues and friends that he positively impacted throughout each migration.

Dave Martyn

Author

Share article:

Dave currently serves as a Solutions Architect at TCDI supported by nearly 20 years of diverse experiences in eDiscovery and technical problem-solving opportunities. His combination of Lean Six Sigma black belt training and backgrounds in engineering, management, sales and operations provides a unique perspective on people, process and technology. Dave helps TCDI generate and apply creative innovations in the pursuit of efficiency, performance gains and intuitive solutions in technology for its clients. Learn more about Dave.