Recently there has been news about case management systems projects with data conversion error problems. While we have written about this issue before, I would like to share some more thoughts on this important issue.
---
When working with courts on a new CMS project, the issue of data conversion is always an important discussion. Invariably the court's initial position is that all the data must be converted. But let’s examine the issues and potential problems with that approach.
There are two parts to this discussion. The first part is for closed cases. As mentioned in my previous article, your court’s old CMS database is not designed the in the same way or using the same technology as a new system. It may even be using obsolete and/or unsupported database software. It is the “square peg that you are trying to force into the round hole”.
Further, data conversion software tools may not work with it? And let’s just say it, the old data may be rife with data errors for a myriad of reasons? It should be segregated into its own subsystem with “warnings” for that reason alone.
Next, the programmers today may not understand your old CMS technology? If they don’t understand it, how are they going to know what and how they need to convert it accurately?
What is the purpose of converting old closed cases? To search and find parties and previous court cases, right? This is for historic research, to pull data into the new system, or link new cases with old. Nobody cares about the ten motions for hearing or the five requests to compel discovery recorded in the case history? The key thing that persons searching case histories wants is the case result, whatever that is.
My general recommendation is to convert the case parties, filing date, result date, result, and if you have it or wish to scan it, the final decision document for closed cases.
The second part of the discussion is for active cases. The approach depends on how many cases you have open? I have often proposed a “jump off the short cliff strategy”. This plan keeps the old open cases on the old system until they are terminated for a period… say one year. At the end of the year the court then simply re-enters the remaining cases into the new system allowing the data to be reviewed and corrected as needed.
But if you are in a large court, you will need to do some serious planning for converting and validating the data. This will be expensive. There is just no other way. But maybe some of our readers have some ideas to share below?
Last, to convert your cases into a useful format I recommend looking at using XML technology that your new database programs can search just as it does with the new data system. This approach works with old Cobol flat file and ISAM database files as well as relational databases since the 1980’s. Here is a Microsoft support article that explains how XML data can be stored and used by SQL Server as one example of how this works:
The basic lesson is to please approach data conversion with a detailed plan and goal. "Everything" is not an answer.
What is your definition of a large court?
ReplyDeleteAn excellent question. Many state court CMS are statewide they obviously qualify. For local courts, I would say five or more judges would be considered large as so many are smaller than that. I have seen courts with few judges be able to simply re-enter their active caseload. And since they are smaller they often don't bother with data conversion and instead use manual records as their archive.
ReplyDelete