Switching Clinic Software: The Migration Checklist (Export, Map, Test, Cut Over)

Switching clinic software is a project with four phases, export, map, test and cut over, and almost every migration story that ends badly skipped the third. The data came out, went in, and the first Monday revealed that dates of birth had landed as appointment dates. This checklist is the version that does not end that way. It applies whichever platform you leave and whichever you join; the comparison pages cover the choosing, and this covers the moving.

Phase 0: before you give notice

• Read the contract. Notice period, retention after cancellation, export rights. Put the dates in a calendar.
• Export everything, now. Not after notice. Reviews describe exports that need a support request and weeks of waiting; start the clock before the vendor knows you are leaving.
• Open the files. A CSV you have not opened is not an export. Check that notes have dates and authors, documents are the originals, and the patient count matches the dashboard.
• Keep two copies, one off the machine that will be wiped.
• Set a finalize-notes date. Unsigned notes are the item most often lost. Every clinician signs what is open before their data moves.

Phase 1: export

Work through the list and tick what you have:

Data	Format you want	Verify by
Patients and contacts	CSV	Count vs dashboard
Appointments, past and future	CSV with clinician, type, status	Future count vs diary
Clinical notes	Structured where possible, plus PDF per patient	Sample five, check date and author
Documents and images	Original files, per patient	Open a sample
Consent and intake	PDF plus answers where available	One per completed form
Messages	CSV or export per patient	Spot-check a thread
Invoices and payments	CSV plus PDF	Open balances total
Insurance details	In the patient export	Payer and ID present
Packages, memberships, credits	CSV	Remaining balances listed
Recurring appointment series	CSV of occurrences	Series recreated later

Anything the old vendor cannot export is a decision: keep the old account readable for its retention period, or re-key the item by hand. Make the decision now, in writing, rather than on go-live morning.

Phase 2: clean and map

• Deduplicate patients. Match on phone and email, then on name and date of birth, and merge before import. Duplicates imported become duplicates forever.
• Archive the inactive. Patients not seen in several years can be imported as archived, so the day list is not cluttered with them.
• Map fields in a table. One row per source field: source name, destination name, format rule, example. Dates are where migrations die: agree the format before a single row moves.
• Map appointment types. The old system's forty types become the new system's twelve. Decide the mapping and the durations, rooms and reminder rules for each.
• Map clinicians, rooms and locations. Every appointment references them; the references must exist first.
• Decide the note strategy. Structured import where the new system supports it, PDF per patient on the record otherwise, or both.

With Capra, the onboarding lead builds the mapping table with you and keeps it; it becomes the test script for the next phase.

Phase 3: test

The phase everyone skips.

• Sample import. Twenty patients across every clinician and appointment type, into a sandbox. Open five records and walk them: contact details, next appointment, last note, a document, an open invoice.
• Fix the mapping, re-run the sample, repeat until five records in a row are clean.
• Full import into the sandbox. Verify counts: patients, future appointments, open invoices, documents. Each must match the export.
• Test the patient side. Send yourself a reminder as a test patient. Open the portal link. Complete a form. Check that it landed on the record.
• Test the integrations. Calendar sync, accounting, any clinical or claims connection, with a test appointment and a test invoice.
• Train on the sandbox. Staff practice on real-looking data before the real data arrives.

Phase 4: parallel run and cutover

• Choose the cutover date. A Friday evening, not the day before the busiest session, inside the old notice period.
• Parallel fortnight. From a dated morning, every new booking goes into the new system. The old one stays open, read-only in practice, for reference.
• Message patients two weeks out, on the channel they use: the practice is changing systems on the date, appointments carry over, reminders will come from a new number, a portal link will follow with nothing to set up.
• Delta export on cutover evening. Anything that changed in the old system since the main import, imported and verified.
• Final count check. Patients, future appointments, open invoices, documents. If a number is off, find out why before Monday.
• Old system to read-only. Nobody writes to it after cutover, however familiar it feels.

Phase 5: after

• First-week watch. Reminders delivered, portal links opened, calendars synced, invoices raised. Fix anything the first week finds.
• Keep the old account readable for its retention period, and take a final archive export before it closes.
• Cancel in writing and keep the confirmation.
• Review the reminder and booking rules a month in, because the move is the best moment to fix what was wrong with them.

The counts, on one line

At every step, four numbers must match the export: patients, future appointments, open invoices, documents. If they match, the migration is probably clean. If they do not, something is lost and the step is not finished.

Common failure points, and the step that catches each

Migrations fail in the same handful of places, and each one has a step above that exists to catch it.

Dates imported in the wrong format, so a date of birth becomes an appointment date or a 3 March becomes a 3 March in a different year: the field-mapping table with an example per row, and the sample import.

Duplicate patients, because the old system had three records for one person and the import faithfully created three: deduplication before mapping, and the merge queue afterwards.

Future appointments missing their clinician or room, because the clinician list was imported after the appointments: map clinicians, rooms and locations first.

Notes present but unreadable, because the structured import dropped formatting and nobody kept the PDFs: the note strategy decision, both structured and PDF.

Reminders sent to patients who had opted out, because the opt-out flag was not in the export: a column in the mapping table, and a test patient with the flag set.

A reminder from an unknown number on the first morning, reported as spam: the patient message two weeks before cutover.

Counts that do not match and nobody noticed until a patient did: the four-number check at every step.

None of these is exotic. They are the reason the checklist has a test phase, and the reason the parallel fortnight exists.

How Capra runs it

Your onboarding lead takes the export of patients, appointments, notes, documents and invoices from your current system, or pulls it with you, maps it field by field into Capra and checks the import with you before go-live. Scheduling, reminders and messaging are live within a few days; integrations are built for you during onboarding; and the lead stays your contact after go-live, in UK and UAE hours. The practice management software page covers the platform you move to, the patient engagement page covers the patient messages around the move, and a demo will walk the checklist with your current system named.