Switching practice software without losing your records

Most therapists who want to change practice software don't, and the reason is almost never the new tool. It's the fear of the move: losing records, confusing clients, and discovering halfway through that something important didn't come across.

That fear is reasonable. It's also manageable, and it gets worse every year you wait, because there's more history to carry each time. Here's how to do it without damage.

Before you move anything

Get your export first, and look at it

Do this before you commit to anything. Log into your current system and export everything it will give you: clients, appointments, notes, payments, forms.

Then actually open the files. This is the step people skip.

You're looking for what didn't come. Common gaps: session notes exported as one unreadable blob, or not at all; appointment history truncated; documents and signed forms not included; custom fields missing.

If your current provider won't give you a usable export, that is itself worth knowing, and it's a reason to move sooner rather than later. Your records are your responsibility as data controller, and a system that holds them hostage is a risk regardless of how you feel about the software.

Decide what you're legally required to keep

This is the part where a migration turns into a records-management decision, and it's worth ten minutes of thought.

Your professional body sets expectations for how long clinical records are retained after therapy ends, and your insurer may have its own requirements. They don't always align, and the retention period is often longer than people assume.

Two things follow. First, "I'll just start fresh in the new system" is not usually available to you for records still within your retention period. Second, migrating is a legitimate moment to delete what you're no longer required to keep, because under UK GDPR you shouldn't be holding personal data longer than you need it. A migration is a natural audit point.

If you're unsure, your professional body's guidance is the place to start, and your insurer will confirm their own expectation.

Keep a frozen copy of the old system's export

Whatever else happens, keep the original export somewhere safe and unaltered: encrypted, backed up, and separate from the new system.

This is your insurance. If you discover in six months that something didn't migrate, the export is the only place it exists. Don't rely on your old provider keeping your account alive; account closure often triggers deletion on a timetable that suits them.

Choosing what actually moves

You do not have to migrate everything, and trying to usually causes the mess.

A useful split:

Move into the new system:

• Active clients: anyone you're currently seeing or expect to see again
• Future appointments
• Anything you need day to day: current contact details, rates, key clinical context

Keep in the archive, not the new system:

• Closed cases within their retention period: these need to be retrievable, not live in your working diary
• Historical financial records: your accountant needs these; your booking system doesn't
• Old form submissions from clients who've finished

The instinct is that a "proper" migration moves everything. In practice, importing hundreds of closed cases makes the new system worse: cluttered search, confusing lists, and a much larger live store of special-category data than you need.

The sequence that works

1. Set up the new system properly first. Your availability, rates, forms, templates, payment connection. Do this while still fully running the old one. No client sees anything yet.

2. Run one real client through, end to end. One session: booked, delivered, paid, noted. This surfaces almost every problem you're going to hit, at a scale where fixing it is trivial.

3. Pick a boundary date. Everything from that date happens in the new system. Before it stays where it is. A clean line beats a gradual drift, which reliably produces the state you're trying to avoid: half your diary in each place.

4. Import active clients only. Contact details, rates, and the clinical context you need to hand.

5. Tell your clients, once and plainly. More on this below.

6. Run in parallel for one billing cycle. Keep the old account open, read-only, for a month. Cheap insurance.

7. Close the old account deliberately. Take a final export first. Confirm what happens to the data, because as controller you should know whether it's deleted and when.

Telling clients

This worries people more than it should. In practice clients care about two things: does the new arrangement still work, and is their private information safe.

A short message a week ahead covers it:

From the 1st I'm moving to a new booking system. You'll get session reminders from a new address, so do add it to your contacts. Your appointments and anything you've shared with me carry across, and your records stay confidential as always. Nothing else changes. Any trouble, just message me as usual.

Three things to get right:

• Warn them about the new sender address before the first email, or your reminders land in spam exactly when you need them not to.
• Don't over-explain. A long message about data migration invites worry that wasn't there.
• Be careful with clients in active distress. For someone for whom the arrangement itself is stabilising, mention it in session rather than by email, and keep it small.

What actually goes wrong

Reminders going to spam. The single most common problem, and it hits in the first fortnight. Warn clients; ask one or two to confirm they got it.

Payment gaps. New payment connections often need verification. Get that done before the boundary date, not on the morning of the first session.

The half-migrated diary. Weeks of checking two calendars, and eventually a double-booking. This is what the boundary date prevents.

Losing the notes you didn't check. Which is why you open the export before you commit, not after.

Migrating everything. A new system full of a decade of closed cases is worse than the one you left.

A note on how we handle this

We'd rather be useful than persuasive here, so: Faresay lets you export your clients and payments as CSV at any time, on any plan including the free one, without asking us. That's deliberate. The ability to leave is part of what makes it reasonable to arrive.

We also have a CSV import for bringing an existing client list in, which is usually the fiddliest part of a move.

If you're weighing us against the alternatives, our comparison page sets it out with the things others do better included.

This article is general practical guidance, not legal advice. Records retention and data protection obligations depend on your professional body, your insurer and your own circumstances, so check with them where a decision turns on your situation.