Every major vendor has a case study or a promotional offer about migration. Not one has a service page. That tells you migration is treated as a way to win accounts rather than as a service somebody is accountable for.
Moving a portfolio of matters from one platform or vendor to another is the least glamorous project in litigation support and the one with the most ways to lose something quietly.
What actually has to survive the move
- Coding decisions. Every responsiveness, privilege, issue and confidentiality call made by every reviewer across every matter. These are the most expensive objects in the repository and the easiest to drop.
- Production history. What was produced, to whom, on what date, in what volume, with what Bates ranges. Lose this and you cannot answer a question about a past production.
- Redactions, as applied — not as annotations that may not survive the export.
- Family relationships and attachment ranges, which break silently.
- Search and tag structures, saved searches, and the folder or batch organization reviewers were working in.
- Privilege log entries and their linkage to the documents they describe.
- Audit trails, which some platforms do not export at all, and which you may need later to show who coded what.
The questions nobody asks until afterwards
Does the destination platform represent coding the same way the source did? A four-value responsiveness field and two boolean fields are not the same object even when they carry the same name.
What happens to documents that were in review but not completed? And to batches assigned to reviewers who have since rolled off?
Can the new platform reproduce a past production exactly, if a party asks for a replacement volume three years from now? That is the test a migration either passes or fails, and it is rarely run.
Validation is the deliverable
The output of a migration is not the data in the new system. It is the evidence that the data in the new system is the same data.
- Document counts reconciled per matter, not in aggregate
- Coding counts reconciled per field per value, so a field that silently lost a value shows up
- A sampled document-level comparison, including the text and the images, not just the metadata
- Every past production re-generated from the new system and compared byte-for-byte against the original volume
- A written reconciliation report, because in two years nobody will remember what was checked
That last item is what distinguishes a migration from a data transfer, and it is the one most often skipped because it costs money and produces no visible feature.
On being the receiving vendor
We are often the destination rather than the incumbent, which means we are the party with an interest in the validation being real. An outgoing vendor has no particular incentive to prove the export was complete. We do, because whatever is missing becomes our problem on the next production.
We will also run a migration where we are neither — validating someone else’s move between two other platforms. That is a cleaner engagement and we are happy to take it.
What we do
Pro-Legal Services, Inc. runs multi-matter repository migrations from Arlington, Virginia — coding, production history, redactions and audit trails carried across, with per-matter and per-field reconciliation, past productions re-generated and compared, and a written validation report.
Small business, minority-owned, SAM registered.
Pro-Legal Services, Inc. runs migrations from Arlington, Virginia, for law firms and legal departments nationwide.
Leaving a vendor or consolidating platforms? Ask whoever is quoting it how they will prove a past production can be re-generated. Then send us the matter list. Pro-Legal Services, Inc. · 1550 Wilson Blvd, Suite 250, Arlington, VA 22209 · 202-955-9400 · info@pro-legal.com