Legacy Litigation Data Migration Guide

Definitions

Practical workflow

1. Set scope, owners, and acceptance criteria

   Define the legacy systems, matter populations, active and closed cases, courts and jurisdictions, parties, counsel, claims, date ranges, documents, evidence, chronology, costs, outcomes, permissions, holds, integrations, and exclusions. Name the litigation operations owner, records owner, data steward, security reviewer, migration lead, and acceptance authority. Write field, relationship, access, file, count, and workflow acceptance criteria before extraction.

2. Build the complete source inventory

   Enumerate case-management databases, court or docket exports, e-discovery workspaces, document repositories, shared drives, email stores, spreadsheets, billing systems, external-counsel reports, evidence stores, chronology files, hold registers, identity directories, audit logs, backups, and local archives. Record source owner, location, format, update time, access path, record counts, relationship keys, retention state, hold state, and known gaps.

3. Capture an independent source baseline

   Create a dated snapshot or controlled extract for every source and preserve the query, filter, export version, timezone, encoding, file manifest, record counts, and extraction logs. Define the freeze window and a late-change procedure. Preserve a read-only baseline before cleanup, deduplication, or transformation changes the only source copy.

4. Identify current authoritative records

   Assign a source-of-truth rule for each standard field. Use the current official court or tribunal docket for proceeding identifiers and filed events where available; approved matter records for matter ownership and scope; conflict or party masters for identity; signed engagement or counsel records for representation; finance or billing records for costs; approved disposition records for outcomes; identity and access systems for permissions; and the hold register or preservation notice for holds. Record effective time, steward, refresh method, and conflict handling.

5. Design the standard litigation target model

   Define target objects and fields for matter identity, matter type, court, tribunal or agency, jurisdiction, docket number, case number, parties and roles, counsel and firm, claims, defenses, issues, dates, deadlines, documents, evidence, chronology events, costs, reserves or amounts where used, outcomes, confidentiality, permissions, holds, source references, and audit history. Distinguish stated, derived, estimated, unknown, not applicable, withheld, and disputed values.

6. Write field and relationship mappings

   For each source object and field, specify target object, target field, data type, format, length, requiredness, controlled vocabulary, source of truth, transformation, null rule, provenance, validation, confidence, and exception route. Map court identifiers, matter numbers, party roles, counsel roles, claim types, event dates, filing dates, limitation dates, document types, evidence references, chronology timestamps, cost categories, outcomes, access groups, and hold identifiers explicitly. Maintain a separate crosswalk for parent-child and many-to-many relationships.

7. Profile quality and classify sensitive records

   Measure missing and conflicting identifiers, invalid dates, duplicate docket numbers, similar party names, stale counsel assignments, orphaned files, broken chronology links, unbalanced costs, inconsistent outcomes, missing hold references, and inaccessible evidence. Classify privileged, confidential, sealed, personal, regulated, minor, victim, whistleblower, trade-secret, and restricted records under the organization policy. Do not infer access or privilege from an ambiguous legacy label without accountable review.

8. Deduplicate without destroying source evidence

   Use stable matter and docket IDs first, then compare court, jurisdiction, parties, counsel, claims, date ranges, document hashes, source locations, chronology, and evidence references. Separate exact duplicates from related matters, amended filings, duplicate exports, copied documents, and genuinely separate proceedings. Select a canonical target record, retain every source ID, and record merge, keep-separate, exclude, unresolved, reviewer, reason, and date decisions.

9. Preserve provenance and integrity evidence

   For each record and artifact, retain source system, source identifier, export or file name, location, source timestamp, extraction time, original value, transformed value, mapping version, file size, version, hash or equivalent integrity evidence where used, custody events, access context, and reviewer. A hash can support comparison of captured bytes; it does not by itself establish authenticity, legal completeness, or admissibility.

10. Transform and stage the migration

    Run versioned transformations for dates, timezones, identifiers, court codes, party names, counsel roles, claim classifications, document types, evidence labels, chronology timestamps, costs, currencies, outcomes, permissions, and hold states. Preserve the original value beside the normalized value where meaning could change. Load a staging area with rejected rows, duplicate candidates, unresolved relationships, missing files, access exceptions, hold conflicts, and manual-review queues visible before production.

11. Validate fields, documents, and relationships

    Use random and risk-based samples across active, closed, high-value, document-heavy, evidence-heavy, restricted, multi-party, multi-court, long-running, and unusual matters. Compare fields to authoritative source evidence, open representative documents, verify evidence and chronology links, check dates and cost totals, test search and reports, confirm outcome records, and exercise allowed and denied access. Include negative cases, missing values, failed files, late changes, and held records.

12. Reconcile every migration stage

    Reconcile source, extracted, transformed, staged, loaded, rejected, excluded, duplicate-candidate, canonical, and target counts for matters, courts, parties, counsel, claims, dates, documents, versions, evidence, chronology events, costs, outcomes, permission subjects, holds, and relationships. Segment by source, court, jurisdiction, matter status, year, sensitivity, and record type. Explain each variance with its cause, owner, disposition, evidence, and acceptance status.

13. Run operational acceptance scenarios

    Have litigation operations, attorneys, paralegals, records staff, finance, security, and representative users complete agreed scenarios: open a matter, confirm court and parties, review counsel and claims, inspect chronology, open a document or evidence item, verify costs and outcome, search by docket, confirm a hold, test restricted access, export an approved record, and find the original source reference. Record defects, exceptions, owners, and retest results.

14. Prepare monitored cutover and rollback

    Version the runbook with final extracts, load order, dependencies, source freeze, late-change handling, monitoring, communications, support coverage, smoke checks, reconciliation queries, access verification, hold checks, decision owners, and stop conditions. Define whether rollback means restoring a backup, removing a batch, isolating target records, re-enabling the source, or correcting forward. Test the runbook on a representative cohort and document irreversible downstream effects.

15. Approve, release, and retain the source

    Obtain named approvals from litigation operations, records or information governance, data stewardship, security or access control, technology, finance when costs are in scope, and the accountable business owner. Signoff should state scope, source snapshot, mapping version, counts, accepted variances, open exceptions, access and hold results, cutover window, rollback boundary, and post-load owner. Keep the legacy source and independent baseline under approved records, privacy, security, and hold controls until separate retirement approval.

16. Reconcile after cutover and close exceptions

    Repeat counts, relationship tests, file-opening checks, source-reference checks, permission tests, hold-state checks, cost and outcome reconciliations, and representative workflow scenarios after each load wave. Review late changes, user edits, integration effects, and unresolved defects. Close exceptions only with evidence and accountable approval, record residual risk, and approve source retirement separately from target acceptance.

Comparison

Limitations and exceptions

• No inventory can prove that every mailbox, local drive, paper file, backup, vendor workspace, court source, or late change was discovered. State the scope boundary, search method, and residual uncertainty.
• A migrated field can be syntactically valid while the underlying court event, party identity, counsel role, claim classification, date, cost, outcome, permission, or hold state is substantively wrong. Qualified owners must review material records.
• A hash or export log can support integrity comparison for a captured artifact, but it does not by itself prove authenticity, legal admissibility, completeness, or a complete chain of custody.
• Deduplication cannot be reduced to a universal similarity score. Related proceedings, amended filings, copied evidence, joint matters, and repeated exports may require separate treatment and accountable review.
• Count reconciliation can pass while the wrong document, evidence item, chronology event, cost, outcome, permission, or hold is attached to a matter. Pair totals with source-based samples and workflow tests.
• Rollback may not reverse notifications, exports, user edits, downstream integrations, court submissions, or decisions made after cutover. Define the recoverable boundary and communications before release.
• This guide is an organization-designed implementation framework and evaluation aid. It is not legal advice, a records-retention schedule, an evidence-admissibility opinion, or a guarantee of legal completeness, preservation, or compliance in any jurisdiction.

Primary sources

Methodology

This guide defines an organization-designed litigation-data migration method, not a universal legal, records, security, or evidence standard. Start with a signed scope and a dated inventory covering matters, courts, parties, counsel, claims, dates, documents, evidence, chronology, costs, outcomes, permissions, holds, source systems, repositories, integrations, and exclusions. Assign current authoritative records to standard target fields: official court or tribunal records for proceeding events where available, approved matter and party records for identity and ownership, counsel records for representation, finance or billing records for costs, approved disposition records for outcomes, identity systems for access, and hold registers or preservation notices for holds. Define target field meaning, type, format, controlled values, requiredness, null states, provenance, security classification, source-of-truth rule, and relationship keys before loading. Snapshot sources independently, preserve originals or controlled references, and version every mapping and transformation. Profile missing values, conflicting dates, duplicate matters, party and counsel ambiguity, broken links, inaccessible files, cost inconsistencies, outcome gaps, and hold conflicts. Deduplicate with evidence while retaining source IDs and decisions. Stage the load, then reconcile full counts and relationships and test risk-based samples across active, closed, restricted, document-heavy, evidence-heavy, multi-court, and edge-case matters. Validate files, chronology, costs, outcomes, permissions, holds, search, reports, and real user workflows. Define acceptance, stop conditions, late-change handling, cutover, rollback, support, and source-retention boundaries before release. Obtain named signoff, repeat post-load reconciliation, keep the legacy source under approved controls, and approve retirement separately. The cited NIST, NARA, W3C, and legal-rule sources provide reference context; they do not guarantee legal completeness or admissibility.

FAQs

Related CaseDocker capabilities

Related guides and resources

• Case management
• Case management information
• Compliance management
• Legal workflow playbooks
• Legacy docket and investigation records migration
• Litigation document chronology guide