Switching legal practice software: a trust accounting migration checklist

The short answer

Switching practice management software is a data migration. Switching with trust accounts involved is a compliance project that happens to include a data migration. Treat trust as its own workstream: reconcile fully before you touch anything, set a hard cutover date, move client balances rather than assuming full transaction history will transfer cleanly, and keep the old system's records accessible for as long as your state requires.

The checklist below walks through that workstream in order. It applies regardless of which systems you're moving between, since the compliance obligations sit with the firm, not the software. It's part of our coverage of law firm accounting and bookkeeping services and our complete guide to bookkeeping for law firms.

1. Reconcile fully in the old system before you begin

Do not migrate until the books are clean.

• Complete a three-way reconciliation as of a recent month-end: bank statement balance, firm trust ledger balance, and the sum of every individual client ledger.

• Resolve every difference. Negative client balances, uncleared items and unexplained variances need to be fixed or clearly documented before cutover, not carried forward into a new system where they'll be harder to trace.

• Produce and save, outside the system: the three-way reconciliation package, individual client trust ledgers with running balances, a trust trial balance or client-ledger summary, and the bank statement with outstanding items listed.

If the old system can't produce clean individual client ledgers, stop and fix that first. Migrating incomplete or inaccurate balances just moves the problem into the new platform, where it's now mixed in with data you have less context on. For what the reconciliation itself needs to show, see what a three-way reconciliation actually requires.

2. Decide what history actually moves

Most new systems accept opening balances far more reliably than full transaction history.

Ask both vendors, in writing:

• Can the outgoing system export individual client trust ledgers with dates, matter attribution, transaction type and running balance?

• Will the new system import full transaction history, or only opening balances as of a cutover date?

• How are trust-to-operating transfers, refunds and adjustments represented in the export?

The Law Society of Alberta's own software-evaluation checklist asks firms the same kind of question before a switch: how data migration will occur, and how the firm can still meet its trust-reporting obligations if it changes software mid-year (Law Society of Alberta). That's worth asking before you sign with a new vendor, not after.

In practice, many firms bring forward only current client balances as of the cutover date and keep the detailed history in archived reports and exports rather than importing it transaction by transaction. How long that archived history has to stay available depends on your jurisdiction, and the range is wider than most firms expect: Arizona's rule sets a five-year floor, North Carolina and several other states require six years, and Illinois, Mississippi and Washington state all require seven years after the representation ends (ISBA; NC State Bar). The ABA's own Model Rule on Financial Recordkeeping suggests five years as a baseline, with jurisdictions free to extend it (ABA). Confirm your own state's rule rather than assuming one of these figures applies to you.

Auditors and bar examiners who ask for records split across two systems are generally working from the same two questions you should ask yourself: do the closing balances in the old system match the opening balances in the new system on a clearly defined date, and is the full history still accessible somewhere. Get both of those right and the split itself usually isn't the problem.

3. Set a hard cutover date and freeze activity

Choose a logical accounting boundary, usually month-end or quarter-end, since that's a point your reconciliation process already treats as a checkpoint.

• Communicate the cutover date to everyone who posts trust transactions.

• On that date, stop recording new trust activity in the old system.

• Pull final balances as of that date.

• Record those balances as opening entries, typically trust receipts or opening balance adjustments, attributed to the correct clients and matters in the new system.

• From that point forward, all new trust activity lives only in the new system.

Running both systems for new transactions after cutover is a common source of duplicated or missing entries. Parallel operation is fine for testing and for finishing open matters' non-trust work, but the trust ledger itself needs a single active home after the cutover date, not two.

4. Validate the new system immediately

Within days of the opening balances being entered:

• Confirm that the total of all client trust ledgers in the new system equals the total transferred from the old system.

• Confirm that the new system's trust bank account, or liability account, balance matches the same total.

• Run a three-way reconciliation in the new system as soon as the first bank statement covering the post-cutover period is available.

• Spot-check a sample of individual client ledgers against the archived reports from the old system.

Any difference needs to be investigated and resolved before the firm relies on the new numbers for disbursements or reporting. This is the step that catches a mapping error while it's still a two-minute fix, before it's buried under a month of new transactions.

5. Keep the old system accessible for the required period

Don't cancel the old subscription the day after cutover if you still need access to historical ledgers, reports or audit trails.

Many firms keep read-only or limited access for the full trust-record retention period that applies in their state, five to seven years in most jurisdictions as covered above, or at least until they're confident every required report has been exported and stored securely outside the platform. A few extra months of subscription cost is almost always cheaper than being unable to produce a client ledger when a bar inquiry or a client request arrives.

6. Align the general ledger and the practice system

If the firm also uses QuickBooks Online, Xero or another general ledger, the cutover affects that system too, whether or not the ledger vendor is involved in the practice-management switch at all.

• Map the trust liability accounts and any clearing accounts so opening balances land correctly.

• Confirm how earned-fee transfers from trust to operating will post after the switch.

• Update bank feeds, payment-processor connections (LawPay and similar) and integration settings so new deposits and fees route to the right places. If LawPay is involved, see our guide to recording LawPay deposits in QuickBooks for how that specific mapping should look.

• Perform the first post-migration bank reconciliations for both trust and operating accounts with extra care; this is where a missed mapping step tends to surface first. If QuickBooks Online is the ledger on the other end, our guide to setting up IOLTA trust accounting in QuickBooks Online covers the account structure to confirm before cutover.

The practice-management system and the general ledger have to keep telling the same story about client funds. A clean cutover in one and a sloppy one in the other just moves the discrepancy somewhere less visible.

7. Document the migration itself

Create a short internal record that includes:

• Cutover date

• Final three-way reconciliation from the old system

• List of opening balances entered in the new system

• Confirmation that totals matched

• Location of the archived historical ledgers and reports

• Names of the people responsible for the migration and for ongoing trust reconciliations

This file becomes useful the first time someone asks, months later, why a particular balance looks the way it does.

Where most migrations go wrong

The patterns are consistent across firms:

• Migrating before the old system is fully reconciled

• Importing summary balances without client-level detail

• Allowing new transactions in both systems after the cutover date

• Failing to archive individual client ledgers for the full retention period

• Treating the software vendor's data migration service as a complete trust-accounting solution

Software vendors can move data. They can't own the three-way reconciliation or the ethical responsibility for client funds. That stays with the firm, through the migration and after it.

How Numetix supports software transitions

We help firms plan and execute the trust side of a practice-management switch. The work typically covers:

• Pre-migration three-way reconciliation and cleanup in the current system

• Mapping of opening balances and client or matter attribution into the new platform

• Validation of the new ledgers against the archived records

• Alignment of QuickBooks or other general-ledger connections, including payment processors like LawPay

• Setting up the ongoing monthly three-way and close process in the new environment

The goal is straightforward: the firm changes software without creating a gap in the trust record, and the books stay audit-ready on both sides of the cutover date.

A practical first step: tell us which two systems you're moving between and your target cutover date. We'll tell you what to request from each vendor in writing before you commit to a timeline. Book 30 minutes with our team. More on how Numetix serves law firms.

Frequently asked questions

How long do I need to keep trust account records after a software switch? It depends on your state. Several states set a five-year floor, several require six, and several, including Illinois and Washington state, require seven years after the representation ends. Confirm your own jurisdiction's rule rather than assuming a figure from another state applies.

Can I just import full transaction history into the new system? Some systems support it, but most firms get more reliable results bringing forward current client balances as of a cutover date and keeping full transaction history in archived exports from the old system.

Is it a problem if my trust records end up split across two systems after a migration? Not inherently. What matters is that the closing balances in the old system match the opening balances in the new system on a clearly defined date, and that the full history stays accessible for as long as your retention rule requires.

Can I run the old and new systems in parallel for trust transactions? Avoid it. Parallel operation is fine for testing or finishing other work, but posting new trust activity in both systems after cutover is a common source of duplicated or missing entries. Pick a single cutover date and give the trust ledger one active home from that point on.

Does my general ledger need to change too if I switch practice management software? Only if the trust liability mapping, clearing accounts, or payment-processor connections feeding it change. Confirm this before cutover rather than discovering it during the first post-migration reconciliation.

What's the single biggest mistake firms make when switching? Migrating before the old system is fully reconciled. Any negative balance, uncleared item, or unexplained variance you carry into the new system is harder to trace once it's mixed in with new activity.