Moving to new practice management software without losing anything

The decision to change systems is usually made in an afternoon. The reason it takes eight months to act on is that nobody knows what will happen to the last six years of records, and not knowing is enough to keep a clinic on software it dislikes indefinitely.

So it is worth being blunt about the answer up front: some of it moves cleanly, some of it moves badly, and some of it does not move at all. Once you know which is which, the migration is a fortnight of ordinary work rather than an unbounded risk.

Ask the export question before anything else

Before you evaluate a single new system, ask your current one — in writing, by email, so you have the reply — what you can export, in what format, and whether you can do it yourself.

The answer changes what you do next more than any feature comparison will. A vendor who exports everything to CSV on demand costs you an afternoon. A vendor who charges a fee, requires a support ticket, or produces a PDF is telling you what leaving will look like, and you want to know that before you have another year of data inside them.

Ask the same question of whoever you are moving to, and hold them to the same standard. A system that is easy to enter and hard to leave is not a better deal because you happen to be entering it today.

What moves, and what does not

The uncomfortable general rule is that structured, simple data moves and clinical narrative does not. There is no shared format for a clinical record, so two systems store the same examination in two shapes that do not correspond.

The sixth row is the one that decides your project. If your clinical history is a structured chart in the old system, it will not arrive as a structured chart in the new one, and a forced conversion produces records that look complete and are subtly wrong — which is more dangerous than an obvious gap.

The strategy that works: run the old system read-only

Do not try to bring the clinical history across. Bring the patients across, start clinical records fresh from the cut-over date, and keep the old system — or a full export of it — available to read.

• New records start clean in the new system, in its own structure, on a known date.
• Old records stay readable, in the shape they were written in, without a conversion inventing detail.
• Nobody has to reconcile two versions of the same note, which is the failure that makes staff distrust the new system in week one.

In practice this is what almost every successful clinic migration looks like, whatever the vendor promised. The clinics that struggle are the ones that tried to make the new system contain the entire past.

Clean the list before you move it, not after

A migration is the only moment you will ever have a complete view of your patient list in a spreadsheet. Spend a day there — it is far cheaper than fixing the same problems inside a new system afterwards.

1. 1Sort by last activity and decide what to bring. A patient last seen in 2014 is a candidate for the archive, not the new list.
2. 2Fix phone number formats in one pass, in the spreadsheet, where find-and-replace exists.
3. 3Find the duplicates — the same person entered twice with a nickname, a maiden name, or a typo.
4. 4Check every row has a name and at least one way to reach the person.
5. 5Decide the date format once, and make the whole file agree with it.

The fourth step is worth doing properly, because a contact record you cannot contact is not a patient record. It is a row that will sit in your list forever, being counted.

Being specific about our own import

Since this article is on our site, the honest version of it rather than the brochure version.

Clinic+ imports patients from a CSV — whatever your column headers look like, in whatever language, the panel detects them and you confirm the mapping before anything is written. It maps eleven contact fields: full name, phone, email, date of birth, gender, national ID, primary doctor, preferred language, address line, city and postal code. Full name is required, and at least one of phone or email. Phone numbers are converted to E.164; the primary doctor is matched if the panel finds a doctor with that name.

What it does not import is everything else: no appointments, no financial history, no clinical notes, no documents. That is not a gap we are working on quietly — it is the position in the table above, applied to ourselves. CSV import and export sit on the Suite and Network plans.

Pick the date, and make it a quiet one

A migration has a day on which the new system becomes the real one. Choose it deliberately, tell everybody, and pick a week when the clinic is not otherwise under pressure.

• Not the start of your busiest season, and not the week somebody is away.
• Not a period end, if your accounts close monthly — you want the finance cut-over to be clean.
• With a fortnight of overlap on both subscriptions. Paying twice for two weeks is the cheapest insurance in the project.

Then enter the next two or three weeks of appointments by hand into the new system before the date arrives. It is dull, it is a couple of hours, and it means the first Monday works.

The part that actually fails is the training

Data migrations rarely fail on data. They fail on the second week, when the front desk is slower than it was, somebody keeps the old system open "just for this one thing", and the clinic quietly ends up running two systems for a year.

1. 1Get everybody into the new system a fortnight before cut-over, with real patients they can practise on.
2. 2Name one person as the one to ask. Not the vendor — somebody in the building.
3. 3Write down the five things each role does daily, and check each person can do their five.
4. 4Set a date on which the old system becomes read-only for everyone, and enforce it.
5. 5Expect the first fortnight to be slower, and put fewer appointments in it on purpose.

The fourth step is the whole discipline. A system somebody can still write into is a system somebody will still write into, and two half-complete records is a worse position than the one you were trying to leave.

A migration is also a permissions reset

One thing worth doing while you are here: do not rebuild your old access list in the new system. Rebuild the list you would design today.

Old systems accumulate accounts — the locum from two summers ago, the "just for today" permission from 2023, the shared login nobody will admit to. Copying that across is how it survives another five years, and deciding who should see what from a blank page takes about an hour.

If you are starting this month

1. 1Email your current vendor and ask what you can export and how.
2. 2Export everything now, whatever you decide afterwards, and check you can open it.
3. 3Clean the patient list in a spreadsheet.
4. 4Import ten patients into the new system and inspect the result.
5. 5Pick a cut-over date in a quiet week, with a fortnight of overlap.
6. 6Train the week before, not the week after.

The second step is the one to do today even if the rest waits until next year. An export sitting on your own drive is the difference between changing your mind freely and being negotiated with — and it is also the answer to what your obligations are if the vendor disappears.

If you are still deciding what to move to rather than how, that is a different question with a different checklist.