Which step comes first when leaving paper, Excel and WhatsApp behind, how a small team adapts, how data is protected during the move, and how long it takes.
Most therapy clinics start going digital in the middle of a crisis. Two clients are given the same slot. A completed measure goes missing before it reaches the file. A message left at reception never gets to the therapist. Or a question arrives that amounts to an audit, and the note from a session six months ago cannot be found.
The decisions made after that moment are usually rushed: a piece of software is chosen, the team is trained for one afternoon, and everyone is asked to use the new system from Monday morning. Three weeks later the paper diary is back on the desk. Six months later there are two systems — and both are incomplete.
When digital transformation fails at the scale of a clinic, it is usually not about the software. It is about sequence, about the team, and about expectations.
It starts with the tool rather than the problem. “We need software” is not a diagnosis. The real questions are: which task lost you the most time this week, and which mistake are you most afraid of making? The answers to those two also tell you which module to start with. A choice made before they are answered ends with a team being pushed to use something it did not need.
Everything moves at once. Calendar, client files, notes, measures, payments, reports — squeeze them all into the first week and none of them settles properly. The team has to learn five new habits at the same time and is worn out before it sees what any of them is worth.
The whole of the past is dragged along. Aiming to migrate ten years of archive in full stops the move before it starts. Even where it is feasible, in practice it becomes a job that never ends, and the team goes on waiting: “we’ll switch when the system is ready.”
Running in parallel drags on indefinitely. Keeping the old and the new arrangement side by side “for a while” looks safe. What actually results is two incomplete records: it becomes unclear which of them holds a given piece of information, and a team forced to check both places eventually goes back to the more familiar one.
Nobody owns it. The clinic owner decides, the team implements, but nobody follows the migration itself. An unowned migration stops at the first snag, because it is not clear whose job it is to clear the snag.
The logic of the sequence is this: each step should leave a gain of its own and be useful without waiting for the next one. The order below does that.
The calendar is the lowest-risk place to start. It holds no clinical data, a mistake can be undone the same day, and the payoff is visible in the first week. Automated reminders on their own move the no-show rate — the first line item that starts to pay for the migration.
There is more to settle at this stage than people expect: session types and durations, the buffer between sessions, the cancellation notice window, who can see whose calendar, how online sessions are marked. All of it can be changed later, but defining it up front makes the system behave by your rules from day one.
The calendar has one more side benefit: the team learns the language of the software without touching clinical data at all.
This is the real migration, and this is where most of the resistance comes from. Asked where they write their notes, most therapists give a personal answer — a notebook, a folder, a template they developed themselves. Changing that is more than changing an interface.
Two decisions are decisive here.
What will the template be? Choosing a structure that suits your modality (CBT, schema, ACT, EMDR, or something like SOAP or DAP) at the outset means the notes accumulate consistently. Changing the template later does not corrupt the old notes, but it does weaken comparability. In a multi-therapist clinic not everyone has to use the same template; which fields must be completed on every file, though, should be common ground.
How will the draft, approval and lock flow work? That a locked note can only be corrected by addendum looks at first like needless rigidity. It is exactly what keeps the audit trail meaningful. It is far easier for a team to learn this in the first month of the migration than in the sixth.
The reason this is left until later is that the rhythm of measurement will not hold until the first two steps have settled. If the calendar is not orderly, when to send them becomes vague; if there is no file structure, where the result should go becomes vague.
Once it does settle, the gain compounds: from the third measurement onwards you have a curve worth discussing. For the detail of this topic in its own right, see Measurement-based care.
Tracking collections, the revenue breakdown, utilisation per therapist — these matter, but they can wait. And once the first three steps are in place, these figures largely produce themselves, because the data underneath them now lives in one place.
Digitising the entire paper archive is almost never the right call in any practice. The approach that works:
Moving paper across is manual work, and manual work has a speed limit. Setting a target of thirty files a day is a target abandoned on the second day. Setting aside one particular day of the week and a particular block of hours is less exciting and gets more finished.
And one more thing: entering these files is clinical work. Handing file entry to reception means unauthorised access to clinical data. Either the therapist does the transfer, or someone separately authorised for the job does.
Moving off Excel is the technically easiest and conceptually hardest of the lot. Easy, because the data is already structured. Hard, because over time an Excel sheet stops resembling a table.
A typical clinic spreadsheet contains: two rows for the same client under two different spellings, three different kinds of information tangled together in a column headed “notes”, a status encoded in a cell colour, and abbreviations only the person who built the sheet understands. None of that migrates automatically.
The clean-up before the migration takes longer than the migration itself, and that is normal:
When the migration is done, compare ten randomly chosen records by hand. The totals matching does not mean the contents match.
This is the most discussed and most postponed part of the move. In a clinic WhatsApp does three separate jobs at once: appointment correspondence, contact with clients between sessions, and coordination within the team. All three living in one place is the source of the problem.
First: messages carrying clinical content sit on a personal device, in a personal account. When the device is lost, when the phone is replaced, or when someone leaves the team, what becomes of those records is anyone’s guess. Second: the message history is not part of the client file, so the clinical record stays incomplete. Third: the expectation of an instant reply creates unlimited availability for the therapist, and that has clinical consequences of its own.
The way out is not to shut it all down at once but to separate the jobs:
Clients need to be told, and how they are told matters. “We don’t use WhatsApp any more” closes a door. “From now on you’ll be able to see and change your appointments at this link, and here’s where to send non-urgent messages” opens one.
In a clinic of three to ten people, adoption is not a training problem. Everyone learns the interface in half an hour. The problem is that the old route is still open.
Name an owner. One person should be responsible for the migration, and that person should have time set aside for it. “We’re all looking after it” is the polite form of nobody looking after it. The owner does not have to be the clinic owner; the most curious person on the team usually does a better job.
Define the roles on day one. Reception not seeing the clinical note is not a setting added afterwards but a boundary built at the start. Which files the supervisor can see, whether a therapist can open a colleague’s client, who can delete an appointment — these are discussed on the first day of the migration. Discussed in the sixth month, they amount to restricting a particular person, and they are taken personally.
Set a date and close the old route. Running in parallel lasts a week, not a month. After the agreed date no appointment is written in the paper diary, and the Excel file goes into a read-only archive. This is a hard decision and it needs to be a hard one; every time it is softened, the team ends up half-using both systems.
Keep a short daily contact point for the first two weeks. A ten-minute questions meeting stops everyone from inventing their own shortcut within a week. The invented shortcuts look harmless — “I still write the note in my notebook and enter it later” — and they are exactly what winds the migration back.
Make the first gain visible. The number of no-shows in the first month after reminders start is worth talking about. A team adopts something when it sees it making its own work easier, not when it is told about it.
Listen to whoever resists. The most reluctant person on the team usually has a fair reason, and it is usually this: for one particular task they do, the new system is slower than the old one. Finding that task and fixing it is quicker than trying to persuade them.
A few concrete indicators are enough to tell whether the migration is working. The point is not to build a dashboard but to be able, two months in, to show an answer to “is this going well” rather than argue about it.
You do not need to track all of these. Picking two and looking at them regularly beats picking five and never looking.
The migration period is when a clinic is at its most fragile in data terms. The data lives in two places at once, temporary copies appear, and unusual people touch unusual files. Given that psychotherapy records are special categories of personal data within the meaning of Article 6 of the KVKK — Turkey’s data-protection law — this period calls for separate care.
Do not email the migration file. An Excel file containing a client list travelling as an email attachment is the most common mistake in these moves. The file goes through the software’s own upload interface; if another route is needed, use an encrypted link with an expiry.
Keep track of temporary copies. The “clients_final_v3.xlsx” left on the desktop, the export file in the downloads folder, the USB stick used as a backup. Once the migration is over these have to be deleted one by one, and remembering to do it without a written list is not possible.
Decide who will see what before the transfer. Defining the roles afterwards means that in the meantime everybody saw everything.
Have a written data processing agreement with the provider. It should be signed before the transfer starts; the data transferred falls within its scope. The list of sub-processors, the retention period, the breach notification window and the return or destruction of data at the end of the contract all belong in that document. For a detailed list of questions, see Writing session notes.
Tell your clients. A change in where records are kept is a meaningful change in terms of the duty to inform. A short notice removes most of the first week’s questions and protects trust.
Decide what happens to the paper archive. What becomes of the paper original of a file once it has been digitised? If the retention period is still running it stays in a locked cabinet; if it has expired, it is destroyed. “Leave it for now” is not a decision; clinical records sitting in a forgotten box are both a compliance gap and a security one.
The “set up in a day” you hear in a software pitch may be technically true. Setting up and migrating are not the same thing. A reasonable frame for a small clinic looks like this.
Preparation (a few weeks). The choice is made, the contract signed, roles and session types defined on paper, the Excel clean-up done. The software is barely touched at this stage, which is exactly why the stage gets skipped. Skipped, it carries over into the migration and takes twice as long there.
Calendar (one to two weeks). The calendar goes live, reminders are switched on, the old diary is closed. This is where the first gain shows.
Files and notes (four to six weeks). Active client files are entered, the note template settles, the team gets used to the draft–approve–lock flow. This is the longest stage, and trying to shorten it usually costs quality.
Measures and portal (two to three weeks). Sending measures becomes routine, and clients are invited to the portal.
Bedding in (a quarter). Add nothing during this period. Opening a new module stops the team from turning what it already has into a habit.
The only thing that upsets this picture is the summer and the holiday periods. Starting a migration in a month when half the team is on leave means splitting the migration in two.
The subscription fee is usually the most visible and the smallest part of the total cost. What also has to be counted:
Against that, the item that pays the migration back fastest is almost always the same: the drop in no-shows and the reduction in time spent on administrative correspondence. Both are measurable from the first month, as long as the state of things before the move was written down somewhere.
What half-finished migrations have in common is that the old route was never fully closed. The paper diary stays in the drawer, the Excel file stays on the desktop, the WhatsApp group is muted but not deleted. On a busy day the team reaches for whatever is most familiar, and from that day on the system starts carrying incomplete data.
The only thing that works against this is a date. After that date an appointment is booked in one place only, a note is written in one place only, and client information is read from one place only. If something is missing it gets fixed — but the fix happens inside the new system, not by going back to the old one.
Digital transformation is not about a clinic looking more technological. It is about there being a single answer to the question of where a piece of information is. Once that answer is clear, everything else — measurement, reporting, handover, audit — becomes possible of its own accord.
Let's talk through how this would work in your own practice.Book an intro call
In about fifteen minutes we'll walk you through the product on a demo built around your practice, and answer whatever is on your mind.
30-day money-back guarantee.