You have picked the new platform, or you are close, and now the managing partner wants a date. The vendor's sales rep said a few weeks. Your office manager, who remembers the last software change, said a few months. Both of them are describing different things, and the honest answer depends on what you are moving and how clean it is.
Here is how we break a case management migration into phases, what each phase waits on, and where the calendar actually gets consumed.
The six phases and what each one waits on
Inventory. List every data type in the old system: contacts, matters, custom fields, tasks, calendar entries, notes, time entries, invoices, trust ledgers, documents, and email. Count records in each, note which are active versus closed, and identify every integration that reads or writes that data. This phase is short if someone at the firm already knows the system well and long if the person who set it up left three years ago.
Mapping. Decide where each old field lands in the new system, what gets merged, what gets renamed, and what gets dropped. Matter types, practice-area custom fields, and status values are the slow parts because the two platforms rarely share a vocabulary. A firm moving from Clio to Filevine, for example, has to decide how Clio's matter-level custom fields become Filevine project sections.
Test migration. Load a copy of the data into a sandbox or a staging account, then have real staff open real matters and look for what is wrong. Expect to run this more than once.
Reconciliation. Compare counts and balances between old and new: number of open matters, number of contacts, total unbilled time, accounts receivable, and, above all, trust balances to the penny. Anything that does not tie out goes back to mapping.
Cutover. Freeze the old system, run the final load, verify the reconciliation again, and open the new system to staff.
Hypercare. The first few weeks after go-live, when someone who knows both systems is on call to fix the field that mapped wrong, the workflow that fires twice, and the document that landed in the wrong matter.
Which phase usually takes the longest
Mapping, followed by the test-and-fix loop. Not the data transfer itself. Moving records is a mechanical job once the rules are settled, and the rules are what the firm has to decide.
The decisions that stall mapping are almost always about custom fields and matter types. A firm with a dozen practice areas, each with its own intake fields built up over years, has to reconcile duplicates ("DOB", "Date of Birth", and "Client DOB" in three different templates), decide which fields are still used, and agree on one structure going forward. That is a business conversation, not a technical one, and it takes as long as it takes to get the right people in a room.
The Clio data migration checklist and the Filevine data migration checklist both front-load these decisions for that reason. Every one you settle before the first test load saves a round of testing.
What stretches the schedule
Document volume is the most common surprise. A firm with a decade of scanned files in Dropbox or a server share can have hundreds of thousands of files, and moving them into a system that expects one folder per matter means resolving every folder that does not match a matter name. Bulk document transfer also runs at whatever speed the destination's API allows, which can add days of pure transfer time on its own.
Data quality is the second. Duplicate contacts, matters with no client attached, closed matters still marked open, and time entries with no matter all have to be handled before or during the load. Clean data moves fast. Messy data moves in rounds.
Integrations are the third. Each connected tool (an intake CRM, an accounting package, an e-signature service, a Zapier account full of zaps pointed at the old platform) has to be reconnected, retested, or rebuilt. Firms often forget these until the week of cutover.
Trust accounting adds a fixed block of reconciliation work that cannot be compressed, and a change in billing platform adds an open-invoices cutover that has to land at a month end.
Picking a cutover date
Choose a date that is a month end for billing and trust purposes, that does not sit inside a trial or a major filing deadline, and that leaves at least a few days of light calendar afterward for staff to find their footing. Fridays are popular because the freeze and final load can run over a weekend, but only if the migration team is genuinely available on Saturday and Sunday.
Work backward from that date. Hypercare needs staffing after it. Reconciliation and the final test load need a clear window before it. Mapping has to be locked before the last test load. Inventory has to be done before mapping starts. Once you lay those out, the timeline is what it is, and pushing the date earlier without shortening a phase just moves the pain into hypercare.
Questions we get
Can we keep working in the old system during the migration?
Yes, through the test phases. The final load happens after a freeze, usually a day or two, during which staff either stop entering data or log what they enter for manual re-entry. Anything entered in the old system after the freeze does not come across automatically, so keep the freeze short and communicate it clearly.
Does a vendor-run migration go faster than an independent one?
Sometimes on the transfer, rarely on the whole project. Vendor teams are efficient at loading standard fields into their own product but usually do not do the cleanup, custom-field mapping, or trust reconciliation. Those still fall to the firm or an independent consultant, and they set the pace. The same factors that set the timeline also drive what a migration costs.
What if we only migrate open matters?
That is a legitimate way to shorten the project, and many firms do it. Closed matters get exported to PDF and CSV, stored where they can be retrieved, and left out of the new system. The trade-off is that conflict checks against former clients have to include the archive, so make sure the archived contact list is searchable.
If you want a realistic schedule for your own data, tell us what you are working with.