Notes from a year of practice-management migrations
A practice-management migration is a category of work the legal-services industry has not yet learned to scope properly. The RFP captures the visible work. It does not capture the work that determines whether the migration succeeds.
A practice-management migration is a category of work the legal-services industry has not yet learned to scope properly. The RFP captures the visible work: software selection, configuration, data mapping, user training, go-live. It does not capture the work that determines whether the migration succeeds. After a year of running migrations between Aderant Expert, Elite 3E, NetDocuments, iManage, and a handful of regional stacks, we have a short list of the gaps that hide outside the RFP.
Trial-balance carry-through. Every PMA migration touches the trial balance through time, billing, AR, and matter-cost data. Most RFPs ask the vendor to “migrate financial data.” What that hides: the source system has accounting periods that close on dates that do not align with the cutover. The chart of accounts in the new system may have additional dimensions (project codes, currency layers) the old one did not enforce. Reconciliation against the old system requires a frozen snapshot at cutover, a parallel run for at least one accounting period, and a published variance threshold above which the migration is rolled back. The RFP rarely names any of this.
Document estate hygiene. The DMS side of the migration assumes the source repository is well-organised. It is not. Across our recent migrations, between 18 and 42 percent of documents in the source DMS were in folders that did not map to a current matter, were owned by a user who had left the firm, or carried metadata that was inconsistent with current taxonomy. The migration is the moment when this surfaces. Two options: copy everything as-is and inherit the mess, or run a hygiene pass that reduces document count by 20 to 30 percent. The hygiene pass adds three to four months. The RFP did not budget for it.
Integration assumption gap. The PMA vendor’s standard integrations are a starting point. Real environments have integrations the vendor has never seen: legacy billing portals, regional tax systems, internal time-capture tools, custom matter-intake forms. Each of these breaks at cutover unless the integration is rebuilt against the new system before go-live. We scope integration work as a separate workstream now, with its own budget, its own timeline, and its own go-live gating criteria. It is consistently 30 to 60 percent of the total migration cost, and consistently absent from the RFP.
Training delivery, not training collateral. The vendor will provide training materials. The materials are fine. They are not the training. The training is delivered by people who understand both the new system and the firm’s actual workflow. We have ended up running these training sessions ourselves on most engagements because the in-house training team has been too thin and the vendor’s training has been too generic. Plan for this. A trained user is the deliverable, not a training video.
Adoption cadence after go-live. The migration is not the project. The project is the operating cadence for the first three quarters after go-live: a weekly review meeting with the workflow leads, an adoption dashboard, a published list of unresolved issues with named owners. We are usually the people who run this cadence for the first ninety days, then hand it off to a permanent ops team the client has built during that window. Without the cadence, the migration regresses; users find workarounds; the new system gets blamed; renewal is at risk.
None of this is hard once it is named. It is just rarely named in time.