Moving in, without the cliff edge.
Most firms do not switch systems on a weekend. They move the live matters first, keep the old system readable, and let the archive follow at its own pace. This is how that works in practice, including the part everyone worries about: client money.
Nothing is deleted, and nothing is held hostage
Moves into OpenLPM
- Clients & contacts — with identifiers, billing details, referral sources and intermediaries.
- Open matters — the priority. Each one mapped to the right practice area and blueprint.
- Documents — folders and files attached to their matters, with the executed copies identifiable.
- Client money balances — as dated opening balances, proved by a reconciliation (§ below).
- Firm knowledge — templates, clauses, procedures, rate cards and fee schedules, rebuilt as the firm’s own blueprints.
Stays where it is
- The old system, readable, for as long as you keep paying for it. Closed files can be looked up there until you decide otherwise.
- The historical archive, by default. Ten years of closed matters move on request, in batches, or not at all.
- Your existing accounts, if you prefer. OpenLPM can record the operational ledger without replacing your accountant’s system of record — decide that with them.
There is no exit fee for taking your data out, in either direction, at any time.
Four phases, typically four to six weeks
Deliberately unhurried. Firms that rush the mapping spend the saved week fixing duplicates afterwards.
| Phase | What happens | Typical duration | Who leads |
|---|---|---|---|
| 1 · Discovery & mapping | Export from the current system; map fields to OpenLPM; agree what counts as a client, a matter and a duplicate; identify the trust cutover date | 3–5 days | OpenLPM + firm administrator |
| 2 · Configure the firm | Practice areas, matter numbering, procedure blueprints, templates and clauses, fee schedules, roles, time rules, notification settings | 1 week (parallel to phase 1) | Firm, with us advising |
| 3 · Move in batches | Clients, then open matters, then documents, then balances — each batch reviewed and signed off by the firm before the next begins | 1–2 weeks | OpenLPM, firm reviews |
| 4 · Parallel run & cutover | Both systems live for one month; staff work in OpenLPM, the old system stays readable; trust reconciled on the cutover date; old subscription ends when you say | 2–4 weeks | Firm, with us on call |
Client money, moved on a stated date
Balances are not “synced”. They are opened on a dated cutover, then proved — which is precisely what a trust account should look like.
- A stated cutover date. Every client balance is opened with the same effective date, so there is a single point at which one system stopped and the other started.
- Opening entries, not balances keyed in. Each opening balance is an entry with a reference to the old system’s record, so it can be traced back.
- A reconciliation that proves it. The bank statement on the cutover date is reconciled against the new ledger; the total must agree before the old system is retired.
- One month of dual visibility. Inbound client money is recorded in both systems during the parallel run, so nothing lands in a gap.
What to move first, and what can wait
Move first — the working set
Documents attached to open matters, current precedents and templates, and anything a client might ask for this month. This is usually a small fraction of the total archive.
Move next — recent history
Closed matters from the last two to three years, in batches, as staff have time. Naming conventions are cleaned during the move, not afterwards.
Move on demand — the deep archive
Older material stays in the old system or an export until there is a reason to bring it across. Moving everything “just in case” is how migration projects fail.
The five things that actually go wrong
None of these are surprising, and all of them are cheaper to plan for than to discover.
| Issue | Why it happens | What we do about it |
|---|---|---|
| Duplicate clients | Years of “Mr Patel”, “Patel, R.” and “Patel Holdings” entered by different people | Duplicates reported during mapping and merged with your approval before matters are attached |
| Inconsistent matter numbering | The old system allowed manual references, or several formats over time | Old references retained as a searchable field, new references generated to your new convention |
| Missing documents | Files referenced in the old system that were never uploaded, or live on someone’s desktop | A missing-document report per matter, so the gap is visible and can be closed before go-live |
| Fee history that cannot be reconciled | Historic billing recorded inconsistently, or in a second system | Historic invoices imported as records for reference; the new ledger starts clean at the cutover |
| Mid-matter trust balances | Clients with funds held across several live matters | Balances opened per client, with the matter allocation agreed with the firm where the old system did not split them |
A printable pre-migration checklist
A migration plan with your name on it
A written plan covering the four phases, the cutover date, the batch schedule and who signs off what. It becomes the document your partners read before agreeing to move.
- Mapping workbook — every field from the old system, and where it lands.
- Batch sign-off records — what was reviewed, by whom, on what date.
- Cutover reconciliation — old total, new total, and the statement that proves both.
- An exit route — you keep a complete export of everything at every stage, including if you change your mind.