Switching migration software: a records-safe checklist

Disclosure: Immi Flow publishes this general practice-management guide and offers migration assistance on stated plan terms. Vendor migration claims were checked on 1 October 2026. Confirm export, import, retention, and support terms in writing before switching.

Changing migration-practice software is a records transfer before it is a software rollout. A new dashboard can work perfectly while an old file note, signed agreement, or client document remains inaccessible.

Plan the move around what the practice must retrieve after cutover. Run a sample first, reconcile it, then expand in controlled batches. Keep the old system available until the new records have been checked.

Start with the client-file duty

Section 56 of the Migration Agents Code of Conduct requires a client file to include the application or matter, service agreements, written communications, oral communication records, invoices, receipts, personal documents, and evidence of returning originals. It requires reasonable steps to keep the file for seven years after the last action.

Section 54 deals with returning documents after a written request. Section 55 requires contemporaneous written records of oral instructions and advice. Moving contact names and open matters is not enough.

1. Inventory every source

List where practice records live today:

• migration software and local document folders;
• email mailboxes and shared inboxes;
• cloud drives and desktop folders;
• accounting and trust records;
• e-signature, messaging, calendar, and task services;
• paper files and scanned archives.

For each source, record an owner, export method, date range, format, and retention decision. Include integrations that may stop syncing when the old subscription ends.

2. Define the complete matter

Create a checklist for one migrated matter. Include client and family details, matter type and status, service agreements, application copies, correspondence, file notes, invoices, receipts, client-money records, source documents, return records, tasks, deadlines, consent, and approval records.

Separate fields that must remain searchable from documents that can remain as readable attachments. Preserve dates, authors, and relationships where they explain the record.

3. Ask both vendors precise questions

Ask the old vendor which data can be exported, which formats are available, whether files and audit events are included, how long read-only access remains, and what happens to backups after closure.

Ask the new vendor which fields and documents it can import, how it handles duplicates and failed rows, whether an import can be reversed, who can access transfer files, and what reconciliation report it provides.

A promise to “migrate everything” is too broad. Attach the agreed field and document list to the quote.

4. Export before changing the old system

Take a full export and record when it was created. Do not clean old data first unless the practice has a documented reason; cleanup can remove evidence or change timestamps.

Store the export securely with access limited to the migration team. Keep a separate copy under the practice's backup and security policy.

5. Test difficult matters

Choose a sample containing an active family matter, a closed matter near the retention boundary, many documents and messages, a changed responsible agent, billing records, returned originals, and non-standard or duplicate contacts.

Compare source and destination item by item. Open documents, inspect dates and authors, follow family links, and produce the exported record from the new system.

6. Reconcile every batch

Record source and destination counts by record type, failed or skipped records, duplicates, unreadable documents, changed field mappings, the reviewer, and completion date. Investigate differences instead of accepting a successful-import message.

7. Rebuild access carefully

Map staff roles before inviting users. Check who can see all matters, assigned matters, billing, trust information, exports, and integration settings. Test owner, RMA, and support-staff accounts, then record approval of the permission map.

8. Run both systems briefly

During a short parallel period, define which system is authoritative for each record. Set a clear cutover time for messages, tasks, documents, and portal activity. Tell staff how to report a missing record and who can pause the migration.

9. Prepare recovery before cutover

Document recovery steps for an incomplete import, incorrect client access, a missing deadline, duplicate messages, an unavailable closed file, or a service outage. Keep source exports and old-system access until agreed checks pass.

10. Close the old system deliberately

Obtain a final export and reconcile changes made during the parallel period. Disable integrations, rotate credentials where needed, and record the contract end date. Confirm what the vendor retains and how deletion works.

Keep a migration record containing the plan, export dates, mappings, exceptions, approvals, and final reconciliation.

Sign-off checklist

The move is ready when every record type has an owner and destination, difficult samples reconcile, exceptions are documented, permissions are tested, deadlines are checked, the practice can export a complete matter, recovery remains possible, and the responsible practitioner approves cutover.

LodgeHQ advertises a Migration Manager importer and assisted imports. Immi Flow pricing advertises migration on certain plans and terms. Treat both statements as starting points for a written scope.

Considering Immi Flow? Test one imported matter before planning the full move.