Five things that broke when I moved three years of patient records into new software
▎
▎ I recently migrated my practice off the system I’d used since 2023 — 6,762 patients, 12,518 visit records, 8,875 payments. It went fine in the end. It did not go fine on day one, and every problem was in the data rather than the software.
▎
▎ If you’re considering a switch, these are the five I’d check.
▎
▎ 1. Verify the money patient by patient before you trust any total.
▎ My headline collections figure was right. Individual balances were not. The old system recorded fees against a treatment plan; the new one read them at visit level, so hundreds of visits showed ₹0 while the plan held the amount. One patient appeared to owe ₹18,900 when she owed ₹500.
▎ Pick ten patients whose accounts you know from memory and check each one by hand. Totals agreeing means nothing — errors cancel out.
▎
▎ 2. Search will fail on names, and it will look like data loss.
▎ Indian names have no single Latin spelling. The same patient was “Shubhash Anghad Misal” in one place and “Subash Angad Misal” in another. Exact-match search finds neither. Staff conclude the records are gone and start re-registering people who are already there.
▎ Test by searching for twenty regulars, spelled the way your receptionist would type them — not the way they’re stored.
▎
▎ 3. Names and gender arrive as raw text.
▎ Mine came across lowercase across nearly every row. Cosmetic, but a case paper reading “male” instead of “Male” makes staff distrust the whole system on day one, and trust is hard to win back.
▎
▎ 4. A course of treatment usually has nowhere to live.
▎ A root canal is one job across five visits — consult and quote, RCT, restoration, crown prep, cementation — priced once and paid across the visits. Most software stores visits, fees and payments as three unconnected lists, so the money looks wrong at every individual visit even when the total is right.
▎ Ask any vendor directly: how do you represent one treatment spanning several appointments? The answer tells you a lot.
▎
▎ 5. Test with your real volume, not the demo.
▎ Everything is instant with twenty demo patients. With seven thousand and three years of history, my patient list took 11.7 seconds to open. Same code, same machine — just real data. Ask for a trial you can load your own export into.
▎
▎ What I’d do differently: run both systems in parallel for two weeks. I was confident in the import and still found problems that only surfaced with a patient in the chair.
▎
▎ Happy to answer questions if anyone’s mid-migration.
▎
▎ Disclosure: I’m a practising dentist and I also build dental software, so this migration was into something I wrote myself. The problems above are the data’s, not any particular product’s — you’ll meet them switching between any two systems. Not selling anything here.
.
