Migrating to a new case management system means moving years of matters, contacts, notes, and documents without losing anything important or breaking the connections between them. A successful law firm data migration follows a clear sequence: inventory, decide what moves, clean, map, test, validate, and cut over.
This checklist walks through each step, based on the case management migrations BRIO has delivered for law firms moving to Litify and Salesforce.
1. Inventory what you have
- List every system that holds case data: your current case management system, intake tools, spreadsheets, accounting, and calendars.
- Identify where documents live: document management systems, network drives, email, and cloud storage.
- Estimate volumes: the number of matters, contacts, notes, and documents, and total file size.
- Note the systems that will be retired and the date their access or licenses end.
2. Decide what needs to move
Not everything has to come along. Moving less can make the migration faster, cheaper, and cleaner.
- Decide which matters to migrate: all of them, only open matters, or closed matters within a certain number of years.
- Decide how much history to bring: every note and activity, or a summary.
- Confirm your records retention obligations before excluding anything.
- Plan how staff will reach older records that stay behind, such as an archive or a read-only copy.
3. Clean up the source data
- Merge duplicate contacts and organizations.
- Close matters that are finished but still marked open.
- Standardize values that were entered inconsistently, such as case types, statuses, and injury types.
- Identify fields that were repurposed over the years and decide how to handle them.
- Flag records with missing required information.
Cleanup can happen before or during the project. What matters is deciding who owns each fix.
4. Map old fields to new ones
- Map every field you’re keeping to its place in the new system, including picklist values.
- Decide how relationships will be preserved: which contacts belong to which matters, and in what roles.
- Plan for data that doesn’t fit neatly, such as free-text notes or custom fields with no direct match.
- Record the mapping in a data mapping workbook that both teams review and approve.
5. Plan the document migration
- Decide how documents will be organized and linked to matters in the new system.
- Check for file types, sizes, or folder structures that need special handling.
- Plan how to handle documents that can’t be matched to a matter.
- Confirm how document versions and email attachments will move.
6. Run test loads
- Load a sample of data into a sandbox (a separate test copy of your system) before the final migration.
- Include tricky records on purpose: matters with many parties, unusual statuses, and large document sets.
- Fix mapping issues and repeat until the results are right.
- Use a full-size test load to estimate how long the final migration will take. (Our guide to Salesforce sandbox types explains where this testing happens.)
7. Validate the results
Validation is where your firm’s staff are most important. They know what a correct matter looks like.
- Compare record counts between the old and new systems for each type of data.
- Spot-check a set of real matters from different practice areas, comparing them field by field.
- Confirm that documents open and are attached to the right matters.
- Check that reports and dashboards return expected numbers.
- Get written sign-off on the test results before the final migration.
8. Plan the cutover
- Choose your data cutoff: the date and time when work stops in the old system.
- Decide how work that happens during the migration window will be captured.
- Turn off automation and integrations in the new system while data loads, then turn them back on.
- Communicate the plan to every user, including where to work and what to expect.
- Prepare a fallback plan in case the migration needs to pause.
Our guide to planning a data cutoff and freeze covers this step in detail.
9. After go-live
- Run a final validation in production before users log in.
- Keep read-only access to the old system for a set period, if possible.
- Track any data issues users report and fix them quickly.
- Retire the old system and its access only after the firm confirms everything is in place.
Planning a move to Litify? Learn how our data migration team works, or read about a firm that migrated its matters to the cloud.
Frequently asked questions
How long does a law firm data migration take?
It depends on data volume, data quality, and the number of source systems. The final migration often happens over a planned go-live window, but mapping, test loads, and validation happen over weeks before that.
Should we migrate closed cases?
Many firms migrate open matters plus closed matters from a recent period, and keep older records in an archive. Confirm your records retention obligations before deciding.
What is a test load?
A test load is a trial migration of real data into a sandbox, used to find mapping problems and validate results before the final migration.
Who should validate migrated data?
Your firm’s own staff should validate migrated data, because they know what correct matters and contacts look like. The migration team provides counts and reports to support their review.
