How-To

Migrating from a Generic CRM to an IP-Native System: A 90-Day Plan

February 1, 2027 · 5 min read · LeadLex Editorial

The biggest risk in a CRM migration is not data loss. It is duration. A project planned for ninety days that runs to fifteen months consumes the BD function's attention, exhausts partner patience, and arrives at a system nobody is excited to adopt.

A disciplined 90-day plan is achievable. The pre-work is what makes it possible.

Decisions to make before week one

Three calls have to be made before the project starts, not during it.

What to keep, what to leave behind. Not every contact, matter, and note in the legacy system deserves to come across. A firm with ten years of accumulated data probably has three years that are alive, three that need cleaning, and four that should be archived rather than migrated. Decide upfront. The default of "migrate everything" guarantees the project runs over.

Field mapping at the schema level. The new system's data model is not the old system's data model. Forcing a one-to-one mapping recreates whatever was wrong with the old setup. Map the fields that have decisions attached to them (see CRM data hygiene for law firms) and accept that some legacy fields die in the move.

The cutover model. Big-bang cutover or dual-running. For a firm above 50 fee earners, dual-running for a defined window — usually four to six weeks — is the safer path. Big-bang works only with strong partner-side discipline, which most firms do not have on day one of a CRM change.

Weeks 1–2: Export and inventory

Pull the full export from the legacy system. Inventory the schema. Identify the records that are active (touched in the last twelve months by a partner or BD team member), dormant (older but still attached to a live client or matter), and dead (no signal of life). The dead set is larger than anyone expects and is the easiest decision in the project.

In parallel, set up the new system in a sandbox and load a representative slice — perhaps one practice group's worth of data. This is not the migration; it is the rehearsal.

Weeks 3–4: Field mapping and clean

Run the field mapping against the active set. Decisions to lock down: which fields are mandatory in the new system, which are optional, which are computed automatically. The mandatory list should be short — partner adoption dies on mandatory fields more than on any other single factor.

Clean the active set. Deduplicate. Reconcile organisations that exist three times because of legacy entry inconsistencies. Resolve owner conflicts. This is unglamorous work and the temptation is to skip it. Do not. The clean is what gives the new system a chance.

Weeks 5–6: Pilot group onboarding

Pick one practice group. Migrate their slice. Onboard the partners in person, not by email. The pilot's job is not to validate the system — that has been done in sandbox. The pilot's job is to surface the friction points that only emerge when a real partner tries to use the system for a real piece of work.

Expect three to five issues per partner. Fix the ones that matter. Document the ones that do not so the partnership can see they were considered and parked.

Weeks 7–9: Dual-running

Migrate the rest of the firm. Run both systems in parallel for four weeks. The legacy system is read-only by week 8. Partners enter into the new system; BD reconciles anything that lands in the old one. This is the period where the new system either earns trust or loses it, and BD presence is the difference.

Daily standups inside BD, weekly readouts to the managing partner. The readout is short: adoption rate, issues raised, issues resolved, anything escalated.

Weeks 10–12: Cutover and stabilisation

Switch off legacy write access. Run the first full monthly BD report (the format from BD reporting that managing partners actually read) out of the new system. Hold a retrospective with the pilot group and a representative sample of late adopters.

The retrospective question is not "do you like the new system." It is "what would you change in the next ninety days." That question keeps the project alive past go-live, which is where most CRM migrations die — covered separately in why legal CRMs die at the 90-day cliff.

What kills the timeline

Three things, reliably. Scope creep into "while we're at it" projects. A partner faction that did not get consulted upfront and starts negotiating after week four. Trying to clean every legacy record rather than the active set.

Defend against all three by writing them into the project plan as risks on day one. The plan is not a guarantee. It is a way of making the deviations visible early enough to do something about them.