How to switch optical software without losing patient records

The software is rarely the hard part of switching. The hard part is the twenty years of patients, prescriptions, balances and half-finished lab jobs sitting in the old system. Plan the move around those, and the change is a weekend. Ignore them, and you'll be looking things up in two systems for a year.

1. Find out what you're allowed to take

Before you sign anything new, read your current contract or ask your vendor in writing:

• Who owns the data? It should be you. Patient records belong to your practice, not your software company.
• What format do they export in? Spreadsheet (CSV) files are the most useful. A PDF of every chart is a backup, not a migration.
• What does an export cost, and how long does it take? Some vendors charge, some take weeks. Ask before you give notice.
• When does your access end? Keep read-only access for at least a few months after you switch, for the odd lookup.

2. Know what usually transfers

Usually transfers	Sometimes transfers	Rarely transfers
Patient names, contact details, dates of birth	Purchase and invoice history	Lab job history and statuses
Spectacle prescriptions	Contact lens prescriptions	Notes in free-text fields
Outstanding balances	Insurance plan details	Scanned documents and images
Recall dates	Frame inventory	Audit trails

Ask your new vendor for this list for your old system specifically, and get it in writing. "We migrate everything" is not an answer.

3. Clean up before you export

A migration copies your mess faithfully. Spend an afternoon first:

• Merge obvious duplicate patients.
• Close or write off balances you know are dead.
• Finish or cancel lab jobs that are months old.
• Count your frame inventory, or at least the boards, so the new system starts with real numbers.

4. Pick the cut-over day

Choose a quiet day, usually a Sunday or the first day after a holiday. The sequence that works:

1. The week before: do a trial export and import. Check twenty patients you know well, field by field.
2. The last day on the old system: take the final export after closing.
3. Overnight: the final import into the new system.
4. The first morning: staff work in the new system only. The old one is for lookups.

Running both systems in parallel for weeks sounds safe, but it doubles the typing and guarantees they disagree. A short, planned overlap of a day or two is enough.

5. Handle what's in flight

These are the items that cause the phone calls in week one:

• Lab jobs already ordered. Keep a printed list of open jobs with tray numbers and the lab. Enter each into the new system as it comes back, or before.
• Deposits and balances. Reconcile the total owed in both systems on cut-over day. They should match to the cent.
• Gift cards and store credit. Bring the balances over, and keep a list of codes.
• Appointments and recalls. Make sure future bookings and recall dates came across, or your next month's schedule is empty.

6. Train for the counter, not the manual

Two short sessions beat one long one: the first before go-live on the everyday tasks (find a patient, enter a prescription, make a sale, order a job), the second a week later once staff know which questions they actually have. Keep a one-page cheat sheet at each station for the first month.

A checklist to take to vendors

• Will you do the migration, or give me a template?
• Which fields from my current system come across, and which don't?
• Can I see a trial import with my own data before I commit?
• Who checks the import, and what happens if something's wrong?
• How are open lab jobs, balances and gift cards handled on cut-over day?
• How much training is included, and is it on my own data?

A good vendor answers these before the contract, not after. If they can't, the move will be harder than they say.