Switching from Clinic Office

Why groups look at switching

Clinic Office holds your practice together, and it has held a great deal of it for a long time. What tends to drive the decision is not a single failure but an accumulation: the clinical detail that lives in custom fields nobody can report on, the finance history that never quite reconciles, the questionnaires that exist as data but not as anything you can use, and the growing realisation that you are running a modern surgical group on a record you cannot query. The barrier isn't loyalty — it's the fear that a decade of history won't survive the move.

Both of these are specific to Clinic Office, both are invisible until after go-live, and both are the reason we will not quote this migration from a feature list alone.

1. Most of your clinical data is not in the obvious fields. Clinic Office exposes a tidy set of standard patient fields — and then puts the substance of your practice in custom fields behind them. On the group we moved, that was 218 populated keys carrying clinical history, GP details and three separate questionnaires. A migration that maps only the documented fields produces a patient list that looks complete and is clinically empty. We counted every key and mapped all 218.
2. Unpaid invoices in Clinic Office are usually not debt. Payments taken outside the system frequently never get marked against the invoice, so the outstanding balance in Clinic Office bears no relation to what patients actually owe — on the group we moved, an apparent multi-million-pound ledger was genuinely zero. Import that naively into a live system and your new platform starts emailing thousands of patients to chase money they paid years ago. We establish the real position with you before a single invoice moves.

1. We connect directly to Clinic Office. This is an API migration, not a CSV hand-off — we read patients, appointments, invoices, payments, staff, clinics, rooms, case notes and documents from the source itself, so nothing depends on what an export screen chooses to include.
2. We count before we design. Every field, including the custom ones, is counted on your live data before a line of mapping is written. You get told what is actually populated in your system, which is frequently not what anyone expects.
3. De-duplication happens before anything links up. Patient matching runs first and conservatively: near-matches go to a review queue for a human decision rather than being fused automatically. Merging two different people is far harder to undo than merging two records later.
4. Bulk history imports while you keep working. Patients, appointments, money, notes, documents and questionnaires all move ahead of your switch date, with Clinic Office still live in front of your team.
5. Your team validates against the source. You spot-check your own patients while you still have Clinic Office access. Imported notes are prefixed so it is always obvious what came from where.
6. Cutover is one short pull, not a long night. On the eve of go-live we pull the forward diary — minutes, not hours — because everything else is already in. You sign the migration report; then, and only then, billing starts.

Groups typically retain a single read-only Clinic Office licence afterwards, so nothing ever depends on the migration being perfect on a particular date.

Coming from something else?

We have also migrated clinics from Pabau and CRM history from Salesforce — the latter for this same group, so their enquiries and their clinical records ended up as one person rather than two. See the switching overview for what we have moved in total.