Skip to content

What actually transfers when you change practice software

Migration conversations focus on the new system. The risk sits in the old one. Here is what typically moves, what usually degrades, and what to check before you commit.

Jan Pieterse

The short version

Ask for a test migration of your real database. What comes back tells you more than every demo combined.

Every vendor will tell you they handle migration. Most do, competently. The gap is not usually incompetence, it is expectation: practices assume everything moves across unchanged, and some things do not.

The three tiers

TierWhat it coversTypically
Structured dataClients, patients, appointments, invoices, reminders, vaccination historyTransfers well. This is the part migration tools are built for.
Clinical notesConsult records, SOAP notes, treatment plansTransfers, but often flattened. Structure can collapse into plain text.
AttachmentsImages, lab PDFs, scanned forms, correspondenceThe most variable tier. Sometimes complete, sometimes partial, sometimes not linked correctly.

Where it usually goes wrong

Clinical notes lose their shape

If your current system stores SOAP notes as separate fields and the new one stores them differently, ten years of structured records can arrive as one block of text per consult. Still readable, still legally sufficient, but no longer searchable in the way you are used to. Ask specifically: does the internal structure of a clinical note survive, or only its text?

Attachments detach

Images and documents are stored differently by almost every system. The common failure is not that files are lost, it is that they arrive without the link to the right patient. Ask how attachments are matched, and check a sample of the oldest ones, which is where matching usually breaks.

Historical invoicing flattens

Line-item detail on old invoices sometimes collapses to totals. Rarely a clinical problem, occasionally an accounting one. Worth knowing before your accountant discovers it.

Inactive records get dropped

Some migrations exclude clients marked inactive or deceased patients, to keep the new system tidy. That is often reasonable and occasionally a serious problem, particularly where records must be retained for a defined period. Ask what the cut-off is and make sure it is your decision, not a default.

The one thing to insist on

A test migration against a copy of your real database, before you sign.

Not a sample. Not the vendor's demo data. Yours. Then check, in this order:

  • Pick five long-standing clients and verify their full history arrived
  • Open the oldest clinical note you can find and see what it looks like now
  • Find a patient with imaging and lab results and confirm both are attached to the right animal
  • Check a client with a credit balance or a payment plan
  • Check a patient with an active repeat prescription

Those five checks catch most of what goes wrong, and they take an afternoon.

Keep the old system readable

Whatever the migration delivers, keep your previous system accessible in read-only form for at least a year, and keep an exported copy of the raw data somewhere independent of both vendors. It is cheap insurance, and the one time you need it you will need it badly.

Plan for the dip

Every practice is slower for the first few weeks after a migration. That is normal and it is not a sign the choice was wrong. Book lighter for the first fortnight, keep someone senior free to answer questions, and expect the team to be frustrated before they are faster. Practices that plan for the dip get through it. Practices that expect a seamless switch tend to conclude the software is bad when what they are feeling is unfamiliarity.

About the author

Jan Pieterse

Editor

Jan edits The Best Vet Software, and reviews everything published here before it goes out.