How to Switch From Crystal PM Without Losing Patient History

Most practice owners who are unhappy with their software stay put anyway, and the reason is almost never features. It is the chart. Somewhere in your office is a machine holding every exam you have performed, every refraction, every retinal image, every unpaid balance. The prospect of moving that is genuinely frightening, and vendors who wave it away as "seamless" are not being straight with you.

Migration is not seamless. It is a project with a scope, a sequence, and a validation step. Practices that treat it that way come out fine. Practices that treat it as a switch to be flipped are the ones telling horror stories at conferences.

This guide is written for an independent optometry practice leaving Crystal PM specifically, though the sequence holds for any on-premise system.

Know what you actually have

Before you evaluate a single replacement, inventory what is in your current install. Crystal PM is typically deployed as a Windows application running against a database on a server in your own office, which means your data is physically in your possession. Confirm that is how your practice is set up before you plan around it.

Practices consistently underestimate the number of distinct data types involved. A realistic inventory:

• Demographics and contacts — names, addresses, phone numbers, insurance assignments, family linkages
• Exam records — the clinical body of work, usually the largest and most structurally complicated set
• Prescription history — spectacle and contact lens Rx, with dates and prescriber
• Images and device output — fundus photos, OCT, visual fields, topography, often stored as files referenced by the database rather than inside it
• Ledger and open receivables — posted payments, patient balances, insurance aging
• Appointments — future bookings first, historical attendance second
• Optical inventory — frame stock, lens catalogs, vendor pricing
• Scanned documents — signed forms, referral letters, outside records

Write down roughly how many records each contains. Those counts become your reconciliation targets later, and they are useless if you gather them after the migration has begun.

Settle the export question before you sign anything

This is the step practices skip, and it is the one that determines whether the whole project is pleasant or miserable.

Ask your current vendor, in writing, what a full data export looks like: which tables and fields are included, in what format, on what timeline, and at what cost. Some systems provide a customer-accessible export utility; others require the vendor to produce the extract on request. Either answer is workable. What you cannot work with is finding out during go-live week.

At the same time, read your agreement for three specific things: who owns the data, what notice period termination requires, and whether support continues through a transition. None of that is unusual to ask about. A vendor's willingness to answer plainly tells you something either way.

Decide what moves and what gets archived

Here is the part nobody enjoys hearing: not everything should come with you, and trying to bring everything is a common cause of failed migrations.

Structured data — demographics, Rx history, ledger balances, future appointments — maps cleanly between systems and should migrate. Richly formatted clinical narrative often does not, because your old system's exam template and your new one's are different shapes. Forcing a mapping produces records that are technically present and clinically unreadable, which is worse than not migrating them at all.

The workable pattern for most practices is a split. Migrate structured data plus a defined window of recent clinical history — commonly the last two to three years, or the last two exams per patient. Then keep a read-only archive of the old system for everything older.

That archive is not a compromise. It is a legitimate part of the plan, and it is cheaper and safer than a heroic full-history conversion. Keep it accessible for as long as your state's record retention rules require.

Sequence it so problems surface early

Migrate in dependency order, and validate each stage before starting the next. Later data references earlier data, so an error you catch at stage one costs minutes, while the same error caught at stage four costs a weekend.

• Demographics first. Everything else attaches to a patient record, so this set has to be right before anything else lands.
• Then clinical history and Rx for your chosen window.
• Then images, which are usually the slowest stage by volume and the one most likely to need a second pass.
• Then future appointments, as late as possible so the schedule does not drift out of sync while you work.
• Open receivables last, and see the warning below.

A specific warning about open AR

Do not treat open receivables as historical data to be bulk-loaded. Balances mid-lifecycle — claims submitted but unpaid, partial patient payments, insurance in appeal — frequently do not survive a mechanical transfer with their aging intact, and a misstated balance is a billing error with a patient's name on it.

Two approaches work. Either freeze new charges in the old system and work the existing AR down to a small residual before cutting over, or run both systems briefly, posting new activity in the new system while collecting old balances in the old one. Both are more work than a bulk load. Both are also how practices avoid discovering in March that their aging report is fiction.

Validate with counts, not vibes

"It looks right" is not verification. Before go-live, reconcile against the inventory you took at the start:

• Record counts per data type, old system versus new, with every discrepancy explained rather than rounded away
• Total open AR, which should match to the cent or have a documented reason it does not
• A spot-check sample of twenty to thirty charts pulled deliberately: your most complex patients, your longest histories, your multi-family accounts, not twenty easy ones
• Image spot-checks, confirming files open and are attached to the correct patient and date
• Insurance assignments, since a patient migrated without their plan will fail eligibility on their first visit back

Assign this to a specific person with time protected for it. Validation that is everyone's job is nobody's job.

What the timeline actually looks like

For a single-location independent practice, plan on eight to sixteen weeks from decision to stable go-live. Multi-location adds time. A typical phase breakdown:

• Weeks 1–3 — Data inventory, export terms, contract review. Owned by the practice owner or manager.
• Weeks 2–4 — Vendor evaluation and demos. Owner plus a clinical lead.
• Weeks 4–8 — Extract, mapping, test load, configuration. New vendor plus your internal project lead.
• 1–2 weeks — Validation and reconciliation. One named internal owner.
• 1–2 weeks — Staff training, before go-live, not after.
• 2–4 weeks — Go-live on a reduced schedule, then back to normal volume.

Two scheduling notes worth more than they sound. Go live at the start of a week, never on a Friday, so that support is reachable while you are finding out what you missed. And deliberately book lighter for the first three or four days. The practices that suffer most are the ones that went live into a full schedule.

Questions to put to any vendor

• Which data types do you migrate, and which do you explicitly not migrate?
• Who performs the extract from my current system, and who is accountable if it is incomplete?
• Will I see a test load and get time to validate it before go-live?
• What does your migration reconciliation report show me?
• How are images and device files handled, and are they attached to the right encounter?
• What is your recommendation for open AR at cutover?
• What is included in onboarding, and what is billed separately?
• If we later leave you, how do we get our data out?

That last question is a fair one to ask of anybody, including us. A vendor who answers it comfortably is telling you they expect to keep you on merit.

Where IrisMed fits

IrisMed is built specifically for independent optometry, and moving from an on-premise system to a cloud platform is a migration path we handle regularly. Onboarding includes a structured data migration with a test load you validate before go-live, rather than a single cutover you find out about afterward.

Pricing is quoted to your practice's size and volume rather than published as a flat figure, because a two-lane single location and a four-location group are not the same project. If you want a straight answer about what migrating your specific data would involve, that is the conversation to have — before you are committed to anything.

Considering a move off Crystal PM? Schedule a demo and bring your data inventory. We would rather tell you honestly what will and will not migrate than promise you seamless.