Legal operations

How to migrate casework from spreadsheets and shared drives

A controlled migration plan for moving active matters from spreadsheets, email, and shared drives into one case-management system.

Published September 10, 2026Updated September 13, 20265 min readCaseflow Editorial Team

Casework migrations fail when teams move files but not the meaning around them. A controlled transition must preserve ownership, dates, relationships, provenance, permissions, and the ability to prove that important records arrived intact.

Key takeaways

Inventory systems, owners, data types, permissions, and retention constraints before moving anything.
Define the target matter model and cleanse data before import, not after go-live.
Reconcile every migration batch and set an explicit cutover rule for the old systems.

Discover the real source landscape

List every place where active case information lives: spreadsheets, shared drives, personal folders, email mailboxes, calendars, paper indexes, billing tools, messaging platforms, and specialist systems. Identify the business owner, technical owner, record types, volume, export method, permissions, duplicate patterns, and known quality problems.

Do not assume the largest spreadsheet is the system of record. Teams often maintain shadow lists because the official system is incomplete or slow. Interview the people doing the work to understand which fields and informal conventions actually drive decisions.

Design the destination before mapping fields

Define the target model for matters, contacts, organizations, documents, dates, tasks, communications, time, invoices, and access. Decide which identifiers must remain stable and how legacy references will be retained. Establish controlled values for status, matter type, role, document class, and closure state.

Write transformation rules that are repeatable and reviewable. For each source field, specify the target, normalization, default, validation, exception handling, and whether the original value must also be retained.

Pilot with representative matters

Choose a pilot that includes ordinary work and difficult exceptions: old and new matters, large files, unusual permissions, multiple clients, cross-border records, closed matters, and documents with inconsistent names. Import into a controlled environment and ask case owners to validate both completeness and usability.

Count records before and after each batch
Verify samples of critical dates, documents, relationships, and balances
Log rejected and transformed records with reasons
Test permissions using accounts with different roles
Confirm that exported reports reconcile with the source

Cut over without creating two truths

Publish a cutover time, freeze or restrict legacy editing, complete the final incremental migration, reconcile it, and communicate where new work must be recorded. Keep the legacy environment read-only for the approved period rather than allowing two editable case registers.

Archive or dispose of duplicate data only under the organization's retention, legal hold, security, and client-property rules. Record the decision, authority, date, method, and exceptions. A migration is complete when the new system is trusted operationally, not merely when the import job finishes.

What should a case-management migration plan contain?

A case-management migration plan should identify the records being moved, the destination structure, the mapping rules, the validation method, and the point at which the new system becomes authoritative. It should also name the people who approve exceptions and the conditions for pausing or reversing the cutover. Copying folders without these decisions can reproduce the same uncertainty in a new interface.

Prioritize the meaning of the records. A date may be a hearing, a filing deadline, an internal target, or an obsolete reminder; a contact may be a client, an opposing party, or a witness. Preserve those distinctions in the mapping. Keep source identifiers where possible so a reviewer can trace the new record back to the export that created it.

Example: reconcile a pilot before moving active matters

Consider a fictional pilot containing 25 matters, 80 contacts, and 600 documents. Record the export counts, then compare them with the import results. Explain any difference: two contacts may have been intentionally merged, an empty folder may not create a document, or a file may have failed validation. A matching total alone is insufficient if documents have arrived under the wrong matter.

Choose sample cases that include duplicates, long filenames, non-English text, historical dates, unusual permissions, and linked financial records. Ask the actual case owner to open a document, find a deadline, review a contact relationship, and produce a useful export. Test an unauthorized account as well as an administrator; a migration is not complete if it widens access unexpectedly.

Source-to-destination identifiers and approved field mappings
Record counts, failed imports, duplicates, and justified exclusions
Document readability and attachment-to-matter relationships
Date, currency, status, and ownership checks
Permission tests, owner approval, and a documented rollback point

When should the old spreadsheets and shared drives become read-only?

Set an explicit cutover time after the pilot, reconciliation, and business approval. Tell staff where new work must be recorded and how late-arriving changes will be handled. If both systems must operate briefly, define who reconciles updates and how long the overlap will last. An open-ended overlap creates conflicting records and makes later checks harder.

Keep any required source archive accessible only to authorized people under the applicable retention policy. Document the difference between an operational rollback copy, an archive, and a normal system backup. Confirm that the organization can retrieve needed records from the new system before retiring the old access route.