Most firms change practice management software once a decade, if that. So most of the people doing it are doing it for the first time, and most of what goes wrong is predictable. This is the order we work through it in, after moving firms between fifteen different systems.
1. Work out how you will leave before you choose where to go
It is tempting to start with demos. Resist it. What you can get out of your current system, in what shape, and what it will cost to get it, decides more about the project than the demo you liked. A system you cannot cleanly leave is a system you will be paying for long after you stop using it.
Ask three questions of your current setup:
- What data lives in it: matters, contacts, documents, email, time, invoices, trust, the ledger?
- What lives somewhere else and is only linked to it, such as documents in a separate document management system?
- What will your current vendor charge to export it, and how long will they take?
On that last point: it is your firm’s data. Know what you can get out, and in what shape, before you commit to anything new. A good migration team will work with your people to gather everything relevant.
2. Decide what should not come with you
Your data does not become good data just because you have bought new software. Twenty years of a firm’s habits come across with it: three spellings of the same client, contacts with no email, precedents nobody has opened since the rules changed, a matter type that exists because one partner wanted it years ago.
A migration is the one moment you get to fix that, and the only moment anyone will agree to spend the time. Go through it before it lands: what comes across clean, what gets merged, what gets archived, and what should not follow you at all.
3. Treat trust as its own workstream
Trust is the one number in the project that has to be right to the cent. Trust history and balances should be reconciled against the old system before you switch, so the opening balances in the new system are right on day one. Talk to your trust account auditor early, and make sure whoever runs the migration can explain exactly how the transfer will be done.
4. Plan the cutover around a weekend
Allow a minimum of two to four weeks from kick-off, depending on how much data you have and how available your people are. Documents and archived files take longest to extract, so they go first, while the firm keeps working in the old system.
The cutover itself is best scheduled around a weekend: out of the old system by 6pm on Friday with your final reports run, migration over the weekend, live by 8am on Monday. Matter and financial data can take a day or two to import, and a weekend absorbs that gap so there is usually nothing to re-key.
5. Run a trial import
Before go-live, import a copy of your data and let the people who will use it test it. They will find the things a data map never shows: a matter type that maps badly, a field that came across empty, a report that does not add up.
6. Train before go-live, by role, on your own data
Training after go-live is training under pressure. Train beforehand, by role, using your own matters rather than a demonstration database. The person who does trust should get the trust session; the paralegals should get the matter workflow.
7. Check the numbers before anyone relies on them
Balances, documents and workflows should be checked against the old system before anyone depends on the new one. It is the step most migrations skip and most firms regret. Finish with a sign-off: someone at the firm confirms the data has landed.
8. Plan for week two, not just day one
The questions that matter only appear in the second week, when the first invoices go out and the first reconciliation comes round. Make sure the people who moved you are still on hand then.
A short checklist
- List what data you have and where it actually lives.
- Get an extraction plan and a fixed quote before you sign for new software.
- Decide what to clean up, merge and archive.
- Agree how trust will be transferred and tell your auditor.
- Book a weekend cutover two to four weeks out.
- Run a trial import and let staff test it.
- Train by role, on your own data, before go-live.
- Reconcile and sign off before relying on the new system.
- Keep support in place for at least the first fortnight.
If you would like a hand with any of it, see how a LAPM migration runs, or find your current system: LEAP, Clio, Smokeball, Actionstep, Practice Evolve, Yao, Logic Firm, OneLaw, NetDocuments, Affinity, FilePro, Infinity, LawMaster, Open Practice, Clasp.