How to move your clinic to a new system without losing a record
Most clinics don't stay on a bad system because they like it — they stay because migration frightens them. The fear is reasonable, but manageable: failed migrations fail at verification, not at import.
In almost every market, the number of clinics unhappy with their software is far larger than the number that have actually replaced it. The reason isn't satisfaction — it's fear: fear of losing a patient record, of a chaotic week at the front desk, of discovering that old invoices became unreachable the moment the previous system was switched off.
That fear is well founded, but its source is not technology. Migrations that fail, fail for one recurring reason: nobody verified the data was complete before the old system was turned off. The import itself is a matter of hours. Verification is the real project — and it's the part that gets cut, because it's tedious.
The rule you don't break
Do not cancel your old subscription until you have run on the new system for at least a full month and hold a complete copy of your data outside both systems. Continued read access to the old system is the only real safety net, and one extra month of fees is far cheaper than any alternative.
Why data migrations fail
Look across a set of system changes and the same causes come up almost every time:
- Incomplete export: the old system exports the core patient file and leaves attachments, prescriptions, and invoices behind because nobody asked for them explicitly.
- Broken relationships: patient data arrives, invoices arrive, but the patient identifier in the second file doesn't match the first — so the invoices are orphaned.
- Character encoding: an export that isn't UTF-8 turns Arabic names into unreadable symbols, a problem usually discovered after import rather than before.
- Duplicate records: the same patient with three records and three phone numbers. Migration copies the mess and multiplies it instead of cleaning it.
- Bad timing: migrating in a busy week or a peak season, so errors get buried under daily operational pressure.
- No owner: when the job belongs to "everyone", nobody verifies anything.
What you are entitled to take with you
Patient data belongs to the clinic as the data controller, not to the software vendor. In practice, bad vendors rarely refuse an export outright — they make it hard enough to be effectively impossible: export as PDF only, a surprise "extraction service" fee, or a short window before shutdown.
| Data type | Priority | Acceptable format |
|---|---|---|
| Core patient records | Critical | Tabular file, UTF-8 encoded |
| History and diagnoses | Critical | Structured export with ICD-10 codes |
| Prescriptions and medications | High | Table keyed to the patient identifier |
| Invoices and payments | Critical | Full ledger, not a summary |
| Attachments and reports | High | Original files, names linked to the record |
| Future appointments | High | Export with date, time, and clinician |
| Audit log | Medium | Export for archival and statutory retention |
The most-missed line in that table is the financial one. Plenty of clinics migrate patient data and forget open balances, then discover two months later that money owed by patients is no longer visible to anyone. Review the retention and deletion controls in our data protection compliance guide before deciding what to leave behind.
The plan: six weeks, not six days
1. Week one — the trial export
Request a full export from the old system today, not on migration day. The goal isn't the data itself but finding out what's missing: open the files, count the columns, confirm Arabic names render correctly.
2. Week two — clean before you move
Merge duplicate records and normalise phone number formats in the old system. Cleaning a thousand records before migration is easier than after, because you can still see the original source.
3. Week three — the test import
Import a full copy into a staging environment on the new system. That environment isn't for demos, it's for verification: pick twenty random patients and compare their records field by field across both systems.
4. Week four — train on real data
Train staff inside the staging environment using their own data, not dummy records. Training on patients they recognise exposes gaps immediately and halves the learning curve.
5. Week five — run in parallel
Run both systems together for at least one week on scheduling and billing. It's annoying, but it's the only way to find what's missing while finding it still costs nothing.
6. Week six — the cutover
Cut over on the quietest day of your week, pull a final refreshed export the same day, and keep the old system in read-only mode for three months.
Cutover day checklist
- Pull the final export after the last working day on the old system closes, not before.
- Store a copy of that export in two separate places, outside both systems.
- Verify the patient record count: the number on the new system must match the old one exactly.
- Verify total open balances: any financial discrepancy means missing rows.
- Open ten records with attachments and confirm the files actually open, not that links merely exist.
- Review the next two weeks of appointments one by one against the old system's calendar.
- Print or save tomorrow's schedule on paper as the front desk's fallback plan.
- Give staff one channel for reporting anything broken during the first week.
The twenty-patient test
Pick twenty patients who represent different shapes of record: a long-standing patient with years of history, one with attachments and imaging, one with an open balance, one with a future appointment, and one under insurance. If all twenty come through intact, the odds of a structural fault in the migration are very low.
What isn't worth migrating
Not everything deserves a seat on the new system. Selective migration is faster and cleaner, and it spares you from carrying ten years of mess into what was supposed to be a fresh start:
- Patients who haven't visited in many years — archive them for statutory retention instead of loading them into the active database.
- Old cancelled and completed appointments — keep the statistics, not every row.
- Unfinished drafts and empty note fields.
- The old system's templates and reports — the new system has its own, and porting the old ones reimports their limitations.
- Test accounts and logins for former employees — a new system is a good moment to clean up permissions.
Contract terms to read before you sign
The best time to guarantee a clean exit is the moment you sign up. Before committing to any new vendor, insist these points sit in the contract rather than in an email:
- Right to export: full data export in a machine-readable tabular format, at any time, with no extra fee.
- Post-termination window: a defined period during which your data stays available for download after the subscription ends.
- Storage location: where data and backups reside geographically, confirmed in writing.
- Onboarding migration scope: exactly what the new vendor's team covers in the migration, and what is billed as extra.
- Data ownership: an explicit clause that patient data belongs to the clinic and the vendor is a processor only.
If you're still comparing systems rather than moving between them, start with our guide to choosing a clinic management system — the best migration is the one you don't have to repeat in two years.
Migrate with a team, not alone
3yadtk runs managed migrations: export from your current system, duplicate-record cleanup, a verification import in staging, and parallel running until you're confident enough to commit.
Talk to us about migrating