The First 90 Days After You Switch Practice Management

Migration is the part of the buying cycle vendors talk about least, because it's the part where the relationship gets tested. Every platform pitch ends roughly the same way: clean data import, intuitive interface, white-glove support, you'll be live in three weeks. Every actual migration unfolds in three roughly predictable phases that look very different from the pitch deck.

Days 1–30: the dual-system phase

The first 30 days are dominated by running both the old and new systems simultaneously. Vendors describe this as a brief overlap. Most firms experience it as a full month of double work, because the firm has matters in flight that started under the old system and can't be cleanly cut over mid-stream.

This is where data migration ambition meets reality. Bulk export tools from the legacy platform produce CSVs that don't map cleanly to the new system's data model. Custom fields the firm added over the years — a status taxonomy unique to the practice, billing codes adapted for one large client, document tags that mean something specific to the litigation team — require manual decisions about how to translate them. Nobody mentions in the pitch that the firm's own customizations are part of what makes the migration hard.

What works in this phase: a written cutover plan that lists every workflow the firm runs (intake, conflict checks, time entry, billing, trust deposits, document filing, calendar, etc.) and assigns each workflow to either the old or the new system for the 30-day window. Firms that try to run every workflow on both systems simultaneously burn out their staff. Firms that pick the workflow assignments in advance — new matters on the new system, in-flight matters finishing on the old, everyone's time entries on the new — get through this phase without paralyzing the practice.

Days 31–60: the behavior-change phase

Once the data is mostly in the new system, the bottleneck shifts. The problem stops being technical and starts being behavioral.

Attorneys and staff have ten years of muscle memory for the old system. They know exactly how many clicks to get from inbox to a matter's billing entry. They have keyboard shortcuts written on Post-its. Their mental model of "how to find that document" points at a folder structure that no longer exists. Even when the new platform is genuinely faster, the first six weeks of using it feel slower because every action requires conscious thought.

This is where most migrations stall. The pattern is familiar: data is loaded, training has happened, the system is technically live — and yet half the firm is still doing time entry in the old tool because the new flow hasn't become reflexive yet. If nothing forces the switch, the dual-system phase quietly extends for another two months.

What works in this phase: a date on the calendar when the old system goes read-only. Not turned off, not deleted — read-only. After that date, new matters, new time entries, new client communications, new billing events live only in the new system. The old system stays available for reference but doesn't accept new information. Firms that pick this date and hold it convert behavior on schedule. Firms that leave the old system fully open often run two systems for many, many months before someone notices and forces the issue.

Days 61–90: the reconciliation phase

By day 60, the firm is operating mostly on the new system. The work in the 30 days is reconciliation: checking that what came across actually came across, and finding the things that didn't. Three categories of issue tend to surface in this phase. Each one is fixable; none of them are obvious until someone looks for them.

First, trust account reconciliation. Trust ledger balances must tie out across the transition. If the old system reported a client trust balance of $4,250 on cutover day and the new system shows $4,200, that's a $50 variance that must be identified and accounted for. Trust accounting in most jurisdictions doesn't tolerate silent variances. This reconciliation must be performed against the bank and the matter ledger, and it must be documented. Firms that wait to discover the variance until they're under a surprise audit are risking a hell of a lot over a preventable issue.

Second, billing cycle continuity. The first invoice run after migration is where missing data shows up. Time entries that were sitting in the old system's draft state but never finalized often don't come across. Expense entries entered under a custom expense code in the old system land under "uncategorized" in the new one until the mapping gets cleaned up. The first invoice cycle usually requires manual review of every invoice, not just the new ones.

Third, the status field. Every firm has a matter status taxonomy that lives somewhere in the old system. Open, Active, Hold, On Reserve, Closing, Closed, Archive — some firms have 10 variants. Almost no two firms' status fields mean the same thing. Migration tools collapse the firm's taxonomy into the new system's default values, and the firm doesn't notice until someone runs a report and the numbers look wrong. Reconciling the status taxonomy in the first month after cutover saves the firm from running misleading reports for a year afterward.

What changes when the migration is over

The thing firms underestimate going into a migration is what they'll see on the other side. When the financial system, the matter ledger, the time entries, the documents, and the communications are all in one place under the matter, the firm's own operating picture becomes legible for the first time in years. That visibility usually exposes problems that had been hidden in the fragmented stack: matters with no recent activity that nobody flagged, time entries written off habitually because the partner didn't remember the work, clients with realization rates running well below the firm's average. None of that was new — it was just invisible across separate systems. The new system doesn't create those problems, but it can certainly bring them to light.

Firms that get through the 90 days and start looking at their own data clearly usually find a couple of revenue recovery opportunities in the first quarter that more than pay for the migration. That's the structural result of having one source of truth.

The migration is the product test

The vendor that handled the pitch well is not always the vendor that handles the migration well. The pitch is a marketing function while the migration is an engineering and operations function, and it's the first time a firm sees what the platform actually does under pressure.

A firm shopping for a new practice management platform should ask three questions about migration before they sign: (1) How does the platform handle the firm's existing custom fields and status taxonomy? (2) Who, specifically, owns the trust account reconciliation across the transition? (3) What does the platform's billing cycle look like the first month after cutover, and what gets reviewed manually?

Vendors that answer those three questions with specifics rather than generalities are vendors that have done this work before. Vendors that wave them off with "our migration team handles it" have not. And you'll see the difference show up around day 31.