Moving your patient database from Excel to dental software

Most clinics do not fail at migration because the software is difficult. They fail because the old spreadsheet is still open a month later, and half the new appointments are being written into it out of habit.

This guide is about avoiding that.

Set a cutover date before you export anything

Pick a date. After it, no new record is created in the old system — not one appointment, not one payment, not "just this once because it was quicker."

Everything else here is mechanics. This is the decision that determines the outcome. Clinics that run both systems "until we get used to it" end up six months later with incomplete data in both, and no way to tell which is authoritative.

Announce the date to the whole team a week ahead, and make one person responsible for it.

Clean the spreadsheet first, not after

It is far easier to fix data in Excel, where you can sort and filter freely, than after it has been imported into structured records.

Work through these in order:

• Split combined columns. "Name" holding Anna Petrosyan needs to become first name and last name. Do it with a formula, not by hand.
• Normalise phone numbers. Pick one format and convert everything to it. +374 XX XXXXXX throughout. Inconsistent numbers are the main reason reminders silently fail after a migration.
• Fix dates. Excel is notorious for storing some dates as text and some as serial numbers in the same column. Sort by that column — anything that sorts oddly is text.
• Remove test and duplicate rows. Sort by phone number: duplicates land next to each other and are obvious.
• Decide what "inactive" means. Patients who last visited five years ago probably should not be imported as active. Tag them before export.

Which fields actually matter

Clinics often try to bring across everything, including columns nobody has filled in since 2019. That slows the migration and imports noise.

The fields that genuinely need to move:

1. First and last name
2. Phone number — the single most important field, because it is how you will reach them
3. Date of birth
4. Allergies and medical alerts
5. Treatment history, even if only as free text
6. Outstanding balance

Everything else is optional. Notes fields can be imported as a single block of text and cleaned up over time as patients return.

Duplicates are the real risk

A migration is the moment two records for the same person become permanent. The usual causes: a patient entered once by mobile and once by landline, or once with a maiden name.

Before importing, sort by phone and by last name and scan for pairs. It is tedious for twenty minutes and saves months of confusion — a duplicate record means treatment history split across two files, which is a clinical problem, not just an administrative one.

Import in two passes

Import ten patients first. Open them in the new system and check that names, phone numbers and dates all arrived intact. Send yourself a test reminder to confirm the phone format works.

Only then import the rest. Finding a formatting problem on ten records costs minutes; finding it on two thousand costs a re-import.

Keep the spreadsheet, read-only

Do not delete it. Save a copy, mark it read-only, and keep it somewhere the team can consult it but not edit it.

You will want it for the first few months whenever something looks wrong. After that it is simply an archive.

Checklist

1. Cutover date agreed and announced
2. Columns split, phones normalised, dates fixed
3. Duplicates removed
4. Ten-patient test import verified
5. Test reminder received on a real phone
6. Full import
7. Old spreadsheet archived read-only

In DOQ, patients import from a spreadsheet and export back out at any time, so this migration is never one you have to repeat under pressure.