Five Things You Should Know When Switching Ediscovery Solutions
When firms or corporations talk about switching ediscovery solutions in the middle of a case, it’s often for very good reasons. Perhaps it was the first project on the application and it didn’t perform as expected; perhaps you hired new litigation support staff with tons of experience and praise for a different technology (and the case has a long enough event horizon to justify the switch); or, maybe there’s a better price out there that’s just too good to ignore. Regardless of the reason why, making the switch always seems like a good idea at the outset--until it comes time to actually implement the new technology.
I recently helped a non-profit organization transition between Customer Relationship Management (CRM) tools. It was striking to me the similarities between that move and a move between litigation technologies. In the process of the CRM transition, I came up with a few things to keep in mind that I think translate well to ediscovery solutions:
1) Don’t try to hide the fact that you’re moving from your current provider.
In all likelihood, they already know you’re on the outs. Beyond that, it is in their best interests to keep you happy through the transition to avoid burning any bridges. Who knows, the next provider might not live up to all the hype and they will want you to come calling when they’re in the market again.
Furthermore, being open about moving will keep you from asking, “Can you send me a copy of my case’s SQL DB?” There might be a scant handful of times that this will be what you need for a transition, but more often it is not. A data dump that you don’t have a map to will just add confusion to the process.
2) Understand what features in your current application are used most and why.
As you look to begin the transition to new technology, work with the new provider to understand what they will need to mimic or backfill your data into their system to enable a smooth transition for those critical items.
Almost universally, there are features in your current solution that you don’t use, or wouldn’t use if you did not have to. If one of these features comes up in discussions with your new provider, give them a chance to help you understand how it could be a benefit, but also don’t be afraid to decide not to implement it for your transition project.
3) Have the right people on your team talk to the new provider about mapping the data.
That person should be someone on your team who not only has a good idea of the day-to-day workings of the current solution, but also understands the data that you are storing and using.
Also note that you don’t have to take it all with you. Be judicious about the information you do transfer into your new solution. In some cases you are better off starting from scratch than trying to fit a square peg into a round hole.
4) Plan for the downtime.
…Because there will be some downtime! Accept it and instead of trying to fight the inevitable, focus on identifying how you can shorten the process as much as possible.
To bide your time, figure out if there are still tasks that can be done in the old system during the transition period. In my case, the non-profit organization continued sending out their weekly newsletter, but they needed to know that any changes to the contact information would be ‘lost’ unless they tracked it well enough to update the new system immediately when live.
5) Jump into the new system as soon as possible.
Training should occur near the time you can start using the new application. No matter how great the training offered is, the knowledge gained will be lost if the trainee can’t put it to use.
Finally, designate a few employees to be the new training and education people during the transition. Building up early internal knowledge of the application helps reduce support costs later and helps you evaluate and tweak the new system faster.