Legacy Docket and Investigation Records Migration to Case Management

Definitions

Practical workflow

1. Set scope, owners, and acceptance criteria

   Define the legacy systems, docket populations, case and investigation types, date ranges, jurisdictions, business units, repositories, documents, notes, events, outcomes, permissions, exclusions, target case-management objects, and cutover objectives. Name the case-operations owner, records owner, data steward, security reviewer, migration lead, and signoff authority. Write acceptance criteria before extraction so completeness and correctness are not redefined after the load.

2. Build a complete source inventory

   Enumerate databases, docket exports, spreadsheets, shared drives, document repositories, email stores, scanned archives, investigation folders, attachments, audit logs, case reports, local workspaces, and vendor or integration sources. Record source owner, location, format, access method, last update, retention state, custodians, estimated volume, full counts, relationship keys, and known gaps. Include rejected, closed, archived, sealed, and inactive populations when policy requires them.

3. Freeze and baseline the source

   Capture a dated snapshot or controlled extract and document the source-freeze window, late-change procedure, extraction version, query or filter, timezone, encoding, file inventory, and count baseline. Restrict changes where feasible and preserve a change log for records created, edited, deleted, reclassified, or received after the snapshot. Do not clean the only source copy before the baseline is independently retained.

4. Preserve provenance and evidence integrity

   For each record and file, retain source system, source identifier, export or file name, source location, extraction time, original timestamp, owner, access context, version, file size, hash or equivalent integrity evidence where used, and custody events. Store the original artifact or a controlled source reference before transforming it. A hash supports integrity checking; it does not prove legal authenticity or establish a chain of custody by itself.

5. Design the target case model

   Define how legacy dockets, cases, and investigations become target matters or cases, parties, opposing parties, allegations, events, deadlines, tasks, documents, notes, evidence items, outcomes, and related records. Establish one meaning for each target field, identifier, status, date, owner, confidentiality value, jurisdiction, source reference, and relationship. Mark fields as required, optional, unknown, not applicable, withheld, or manual review rather than hiding gaps with defaults.

6. Write the field and relationship mapping

   For every source object and field, record the target object and field, type, format, maximum length, requiredness, controlled vocabulary, transformation, null rule, source-of-truth decision, provenance, validation, confidence, and exception route. Map docket numbers, legacy case IDs, investigation IDs, court or agency references, parties, dates, status, responsible team, location, priority, confidentiality, and outcomes explicitly. Maintain a separate relationship crosswalk for parent-child and many-to-many links.

7. Classify records and protect restricted populations

   Identify sealed, privileged, confidential, sensitive, employee, whistleblower, victim, minor, regulated, or otherwise restricted records according to the organization policy and applicable review. Map access groups, matter teams, office or jurisdiction boundaries, external users, retention states, legal holds, and special handling instructions. Require an accountable reviewer for records whose access or classification cannot be inferred safely from legacy metadata.

8. Profile quality and identify duplicates

   Measure missing identifiers, invalid dates, conflicting statuses, repeated docket numbers, similar party names, duplicate files, orphaned attachments, inconsistent jurisdiction codes, stale owners, and broken relationships. Define exact and near-duplicate rules using stable IDs, parties, dates, source locations, file hashes, document content, and human review as appropriate. Select canonical records without deleting source evidence, and log merge, keep-separate, exclude, and unresolved decisions.

9. Transform and stage without overwriting originals

   Run versioned transformations for date formats, timezones, controlled values, text encoding, identifiers, status mappings, file names, document types, and relationship keys. Preserve original values and source provenance wherever a transformation can change interpretation. Load into a staging area with rejected rows, duplicate candidates, unmatched relationships, missing files, validation failures, and manual-review queues visible before production loading.

10. Validate records, files, and relationships

    Use random and risk-based samples across active and closed cases, investigations, jurisdictions, record types, access levels, date ranges, duplicate candidates, long event histories, scanned documents, missing fields, and unusual formats. Compare target values with source evidence, open representative files, check integrity evidence, verify access behavior, test search and reports, and confirm that events, documents, notes, tasks, parties, and outcomes remain attached to the intended case.

11. Reconcile every migration stage

    Reconcile full counts for source records, extracted records, transformed rows, loaded records, rejected rows, excluded records, duplicate candidates, canonical records, documents, attachments, versions, evidence items, events, parties, relationships, permissions, and exceptions. Segment results by source, record type, status, jurisdiction, year, and sensitivity where material. Explain each variance with a source, decision, owner, and evidence instead of reporting only one total.

12. Run user acceptance and operational scenarios

    Have case operations, investigators, records staff, security reviewers, and representative end users complete agreed scenarios: find a case, inspect docket history, verify parties and events, open a document, review evidence provenance, search notes, create a task, confirm restricted access, export an approved record, and locate the source reference. Include negative cases, missing data, duplicate warnings, failed files, late changes, and escalation paths.

13. Prepare cutover and rollback controls

    Version the runbook with final extract steps, load order, dependencies, freeze timing, monitoring, communications, support coverage, smoke checks, access verification, reconciliation queries, decision owners, and stop conditions. Define the rollback boundary before production loading: whether the team can restore a backup, remove a batch, isolate new records, re-enable the legacy source, or only correct forward. Record downstream notifications and user changes that cannot be reversed.

14. Obtain signoff and release in controlled waves

    Require named approvals from case operations, records or information governance, data stewardship, security or access control, technology, and the accountable business owner. Signoff should state scope, source snapshot, mapping version, counts, accepted variances, unresolved exceptions, access results, evidence integrity results, retention or archive decisions, cutover window, rollback boundary, and post-load review owner. Release in cohorts when risk, volume, or source diversity makes a single cutover imprudent.

15. Reconcile after cutover and retire carefully

    Repeat smoke checks, counts, relationship tests, access tests, file-opening tests, source-reference checks, and exception review after each load wave. Keep the legacy source available for the approved period and under applicable retention or hold controls. Do not delete or alter it merely because the target load succeeded. Close exceptions with evidence, record residual risks, review late changes, and obtain a separate retirement approval.

Comparison

Limitations and exceptions

• No migration inventory can prove that an undiscovered mailbox, local drive, paper file, vendor system, backup, or late source change was outside the declared scope. Record the scope boundary and residual uncertainty.
• A hash or similar integrity check can show that bytes match a captured artifact at two points in time. It does not, by itself, establish authenticity, legal admissibility, completeness, or a complete chain of custody.
• A field map can preserve representation and provenance but cannot determine whether a legacy allegation, status, outcome, party identity, privilege label, or investigation conclusion is substantively correct.
• Deduplication is not purely technical. Similar dockets, amended records, repeated evidence, related investigations, and copied files may need separate treatment based on context and accountable review.
• Count reconciliation can pass while the wrong file, relationship, permission, date, or controlled value is attached to a target record. Pair counts with evidence-based samples and workflow tests.
• Rollback cannot always reverse emails, notifications, exports, user edits, downstream integrations, or decisions made after cutover. Define the recoverable boundary and communication plan 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 promise that any case-management configuration satisfies a particular jurisdiction or organization policy.

Primary sources

Methodology

The inventory, field-map, deduplication, evidence-integrity, validation, reconciliation, rollback, and signoff sequence in this guide is an organization-designed migration framework. NIST, NARA, and W3C sources provide reference material for controls, incident handling, records lifecycle, and provenance; they do not prescribe one case-management migration method or establish that a product configuration is compliant. Start with a signed scope statement and a complete source inventory that counts dockets, cases, investigations, parties, events, documents, attachments, notes, tasks, evidence items, relationships, permissions, exclusions, and known gaps. Freeze or snapshot each source, preserve original artifacts or controlled references, and capture source IDs, timestamps, extraction settings, file metadata, hashes or equivalent evidence where used, custody events, and access context. Design the target model and versioned source-to-target map before loading: define field meaning, type, format, controlled values, null rules, transformations, provenance, validation, relationship keys, and exception paths. Profile missing values, conflicts, stale owners, invalid dates, duplicate candidates, broken links, restricted records, unreadable files, and late changes. Deduplicate with documented evidence and keep canonical decisions reversible or reviewable. Stage transformations before production, then validate samples across risk and complexity cohorts, inspect files, verify integrity evidence, test permissions and search, and exercise real case-operations scenarios. Reconcile full counts and relationships at every stage, segment variances, and assign every exception an owner, disposition, due date, and evidence. Before cutover, record go or no-go criteria, monitored runbook steps, rollback boundary, downstream effects, and support ownership. Obtain named signoff from case operations, records, data, security, technology, and the accountable business owner. After release, repeat reconciliation, keep the legacy source under approved controls, close exceptions, review late changes, and approve source retirement separately.

FAQs

Related CaseDocker capabilities

Related guides and resources

• Case management
• Case management information
• Compliance management
• Legal workflow playbooks
• Contract migration validation and QA checklist