Geese. Whales. Frogs. Sharks. All these animals migrate, each for their own reasons: escaping an unfavorable climate, finding a more comfortable habitat, to reproduce, to find food. But there are other types of migrations that are increasingly important in the legal technology world: moving data safely and securely.

What exactly is data migration? Wikipedia defines it as “the process of transferring data between storage types, formats, or computer systems.” That’s a fairly broad statement. However, it has become paramount to master this skill to help support both ongoing operations and growth within a law firm environment. Here’s our story.

• Outgrowing a Tool. Many business professionals tend to follow their inclination to tackle a problem with one of the available desktop tools. Most times, the initially selected tool does the job for a while, sometimes forever. But other times, complexities arise. Data volume may increase. A complex report or calculation may be required. Information may need to be shared. Perhaps buckets of information need to be secured.

In the world of litigation case management (tracking various data points such as case status, venue, plaintiff data, law firms, etc.), this is a frequent occurrence. At the beginning of a dispute a well-meaning professional — sometimes an attorney or paralegal; other times someone in a technology support function — may design a simple application to track and manage this sort of data. This could be a Word table, Excel chart or Access database — or perhaps a litigation support tool, such as AccessData’s Summation or LexisNexis’ Concordance. (Both are an outstanding piece of software for document review but arguably not designed for complex database management tasks).

Initially, the tracking process generally works quite well. But as a litigation expands to hundreds or thousands of cases or plaintiffs (or venues, defendants or law firms), the volume and complexity of the collective set of cases can begin to outgrow the tool.

What sort of tangible problems might users be struggling with? System response time can bog down. Issues with data integrity or quality can arise (i.e., if fields such as law firm names or states, which should be pick lists, are repeatedly typed into text fields, they will probably be typed inconsistently).

It may become increasingly difficult to generate required reports. Users may be increasingly “locked out” of data records they need to update. Or we may be unable to segment data from various user groups as data security requirements emerge.

Bottom line is, just as a growing law firm may outgrow its physical office and need to consider a bigger space, a litigation can outgrow a technology tool.

• Integrating External Data. Be aware that some “problems” might be more back office than user issues. But that does not mean they can be overlooked. For example, consider a situation when a set of cases is being transferred from another law firm to your shop. Or a circumstance when a lateral partner moves from another firm to yours. In either case, a legal technology professional may be asked to support a legal case management system that is operating perfectly fine, but might be built using a tool the technology group cannot or chooses not to support. For example, the law firm IT group may not have a programmer who knows the language used to develop the inherited system. Or, the system may be running on open source software — a type of software your firm has strategically chosen to avoid implementing.

• Decision Point. Whatever the issues, at some point the legal technology professional approaches a crossroad. Can incremental improvements to the current tracking system save the application? Do we want to welcome a particular technology into our shop? Or, is now the time to cut the cord on the old system and migrate the data into a more powerful or standard database platform?

At first blush, the answer may often seem obvious. We may initially think, of course let’s move this puppy into the latest and greatest tool, a technology platform we have come to know and love. But a decision is usually not cut-and-dried.

To be appropriately diligent, we must develop plans, and assess migration costs — including the expense of programming to mimic existing data entry screens, reports and functions. We also must address softer considerations, such as user resistance to change and training.

So, what are some of the key points to consider when assessing and executing a data migration of this nature?

• Project Planning. For starters, develop a comprehensive and independent-minded assessment of the business situation. Estimate the costs of retrofitting vs. converting data/rebuilding. Enumerate the key risks and benefits of both approaches. Ballpark project plans and implementation timelines for both alternatives.

Also, in those cases where the alternative of retrofitting is not feasible, be sure to clearly and articulately explain why. Don’t provide leadership with a choice, if there really is not a reasonable choice to make. You’ll just be wasting everyone’s time.

At the end of the day, endeavor to present the decision makers in your organization with the equivalent of an outside consultant analysis and recommendation for your system. The more legwork a project plan shows, the more likely it is that management will adopt your plan.

• Migration Steps. Assuming a database will be migrated, here are some recommended action steps.

1. First, move data “as is.” I recommend the first step always be to move over all existing tables from the legacy database into what we call “staging tables.” These are database tables which are exact copies of the legacy system tables. Why do I recommend this? Because, inevitably, someone will question whether or not the data was cleanly and completely migrated. If you have an exact copy of the old data, you’ll have that base covered.

2. Map from “old to new.” We’ve found that constructing application screens and sample reports in the new technology and reviewing them with users, even before data is mapped and converted, is a great way to “prototype” a system to the user community.

3. “Clean up” data as you import it into a new technology. If an old system contains 13 different spellings of a city name like “Tallahassee,” don’t migrate trash. That’s just moving a problem from one technology to another. Engage the user community on a frequent basis to bring items like this to their attention so data quality can be improved as the new tool is constructed.

4. Place data into the proper field formats. It’s not uncommon to find case status values that should be a drop-down box, or dates stored in a text field. Just like the “Tallahassee” example, situations like these almost always present data quality problems (e.g., a user can type an invalid date or a status value which does not exist).

Data quality problems make reporting very difficult (e.g., it’s often impossible to create reports using date calculations such as “cases with a response required in the next seven days” if the dates are stored in a field formatted as a text field).

So, when needed, make the extra effort to translate the data in each field into the format which is most logical (date, picklist, etc.). That upfront investment of time will pay off tenfold in the end.

Once these skills are mastered, the benefits are plentiful indeed. From a business development perspective, a law firm now has a nice technology blueprint to offer prospective lateral partners in those situations where they are fortunate enough to bring in new work.

Being able to say, “Sure, we do migrations like this all the time!” is often of great comfort to clients and, if properly packaged, can be a marketing benefit to a law firm as well.

And from an operational perspective, following these data migration guidelines should provide your new system and users with some great day-to-day benefits.

Not exactly the same sort of benefits our friends in the animal kingdom receive from their successful migration, but a happy ending to a challenging situation nonetheless! •