Bringing your patient panel across

Getting the file out of your old system

SimplePractice exports a `.zip`. Take the whole thing rather than one file out of it: Gale reads the clients, the appointments and the balances from inside it, and a zip with only clients loses the other two.

TherapyNotes and IntakeQ export a single clients `.csv`. IntakeQ's own import template is the shape Gale expects.

Something else? Upload it anyway. Gale reads a general CSV by its column names, and if it cannot find a name or a date of birth column it refuses and tells you the headers it actually saw — which is usually enough to see what to rename.

Nothing imports until you say so

Uploading stages the file. It creates no patient records. You confirm clients one at a time, and until you do, nothing from your old system exists in Gale as a patient.

That is also why the report is worth reading before you confirm anything: this is the moment when fixing something is cheap.

Reading the report

What came across gives every record from your file its own row and its own number. Two severities, and the difference is the point:

A missing middle name is not a missing date of birth, and the report is built so those never read the same.

The summary ranks the problems by how many records each one is holding back — four of your six are a date format sends you to one fix instead of six rows.

Recording a value is not importing it

When you type a date of birth on a blocked record, Gale writes it beside the record. The record still reads as blocked, and the row says so.

That is deliberate. The quickest way to corrupt a migrated panel is an editor that accepts whatever it is handed and calls it fixed. Your value is kept, attributed to you, and applied where it belongs — it does not silently rewrite what your old system exported.

The repair chat, and what it will not do

Upload the same export on the report screen and Gale reads its shape — the column names and how the dates are written. Your clients' names, birthdays and contact details are not part of that conversation. Refer to a record by its number; a question carrying a patient's name is refused rather than quietly stripped.

It then offers repairs it measured by re-reading your file, with two numbers each:

• unblocks — records that were not arriving and now would
• corrects — values that were stored wrongly and now would not be

They are separate because they are different promises. A column of `15/03/1990` dates read day-first instead of month-first is the common one, and it usually unblocks several records at once.

Two things it refuses. It will not guess a two-digit year, and it will not choose between readings of a date that is real both ways — `03/12/1988` is a real date in either order, so nobody but you can say which it is. And applying a fix is your act: the chat proposes, and the repair runs when you press the button.

What a good repair looks like

Errors left over after a repair are the success condition, not a shortfall. A repair that cleared every row would have invented the records your file does not contain.

So after a fix, expect the dates that were mis-read to read, and expect the record with no date of birth in the file at all to still refuse. Nothing in your export says what that date was. It needs a value from your old system or it needs taking out — and taking it out, with a reason, is a legitimate finish.

Before you cancel your old subscription, check the migration ledger on the Migration screen. It accounts for every record type — clients, notes, appointments, balances, consents — and only goes green when every record is either imported or explained. That bit is the one to trust, precisely because it stays red while anything is unaccounted for.