Every EMR vendor will tell you migration is "straightforward." It isn't. I've been through four of these now, and the gap between what gets promised in the sales cycle and what actually lands in the new system is where practices lose months of productivity, lose trust with staff, and sometimes lose patients who got a strange gap in their chart history.

If you're planning a switch, the single most useful thing you can do is treat data portability as its own project with its own owner, not a bullet point on the implementation plan. Here's how I think about it after doing it a few times, and what I'd tell any practice owner who's about to sign a contract with a new vendor.

Start with what you actually own

Before you talk to anyone about extraction, pull your current vendor contract and find the data clauses. You're looking for three things: what format they'll export in, what they'll charge you, and how long they'll give you access after termination. The answers are often ugly. I've seen export fees of $15,000 for a mid-sized practice, 30-day post-termination windows, and "PDF only" clauses that effectively trap your structured data.

If you're still in the evaluation phase for your current system, or renewing, this is the moment to negotiate. Written commitments to CSV or FHIR exports at no additional cost, with a reasonable notice window, are reasonable asks. Vendors who refuse are telling you something.

Once you know what you're entitled to, inventory what exists. In most clinics the data lives in more places than people realize:

  • The EMR database itself (demographics, encounters, problem lists, meds, allergies, vitals, labs, orders)
  • Document stores (scanned IDs, outside records, signed consents, imaging reports)
  • The practice management side (appointments, insurance, superbills, A/R)
  • Secure messaging threads and patient portal content
  • Integrations: lab interfaces, e-prescribing history, fax inbound, pharmacy connections
  • Email, SMS, and call recordings if you store any of it

Make a spreadsheet. For each source, note the record count, the export format offered, who owns the credentials, and whether the data is clinically necessary, legally required, or merely nice to have. That distinction matters because it drives scope.

Decide what travels and what stays

You cannot bring everything across cleanly, and you shouldn't try. In practice, I split data into three buckets.

Live data is what clinicians need on day one in the new system: active patients, current medications, allergies, problem list, recent vitals, the last 12 to 24 months of encounter notes, open orders, upcoming appointments, and current insurance. This gets migrated as structured data wherever possible.

Reference data is historical context the clinician may want to look at but doesn't need to interact with. Older notes, resolved problems, archived labs. For most practices this ends up as PDF bundles attached to the patient chart, organized by year or encounter type. It's a compromise, and it's usually the right one. Trying to force a decade of free-text notes into a new structured schema is where migration budgets go to die.

Archive data is kept for compliance but doesn't need to be in the EMR at all. Inactive patients beyond your retention floor, discharged staff records, old billing files. Export it, store it in encrypted cold storage, document where it lives and how to retrieve it. Confirm your state's retention requirements with your own counsel before you decide anything is truly archivable.

Extraction: get the raw material right

The quality of your migration is capped by the quality of your extract. If you accept a messy export, you will spend the rest of the project paying for that decision.

Push for structured formats in this order of preference: direct database access (rare, but gold), FHIR bundles, HL7 v2 messages, CSV exports with a documented schema, and finally CCDA. CCDA sounds clinical and official, and it is, but in my experience the quality varies wildly between vendors. Some produce lovely well-formed documents. Others produce CCDAs where the medication list is a single text blob.

Whatever you get, demand a data dictionary. Field names, data types, enumerated values, and the relationships between tables. Without this, your migration team is reverse-engineering someone else's schema from sample data, and they will miss things. They always miss things.

Run a test extract early. Not the full dataset, just a representative slice: 50 patients across different cohorts (new, chronic, pediatric if relevant, high-document-volume). Load that slice end-to-end into the new system and have a clinician actually use it for a simulated visit. You will find problems. Better to find them in month two than month six.

Cleaning: the unglamorous middle

Clean data in your old system is rare. Duplicate patients, inconsistent allergy coding, free-text medications that should be RxNorm, phone numbers in six different formats, insurance payers spelled four ways. Migration is your one chance to fix this at scale, or at least some of it.

I'd prioritize cleaning in this order. Patient identity first: dedupe on name, DOB, and a secondary identifier, and have a staff member manually review every merge candidate. Getting this wrong creates real patient safety issues downstream. Then medications and allergies, because those drive clinical decision support in the new system. Then problem lists, mapped to ICD-10 where they weren't already. Everything else can be cleaned in place after go-live if needed.

Build a validation report that runs against both the source extract and the loaded destination. Row counts by table. Null rates on required fields. Distribution of enum values. If 12% of your source patients had a primary care provider assigned and only 4% do post-load, something broke in the mapping and you need to know before clinicians do.

Transfer and cutover

The actual cutover is a logistics exercise more than a technical one. The pattern that's worked for me:

  • Full historical load completed two to four weeks before go-live, with the new system running in parallel-read mode
  • A delta load the night before go-live catching everything that changed since the full load
  • A hard freeze on the old system at a defined hour, with staff communicated to repeatedly
  • A final delta the morning of go-live, with sign-off from a clinical lead before patients start arriving
  • The old system kept read-only and accessible for at least 90 days, longer if your contract allows

Staff training should happen on the new system loaded with real migrated data, not vendor demo data. The quirks of your own practice (how you name templates, how you handle walk-ins, how your MA documents vitals) only surface when people are working with records they recognize.

Budget for a productivity dip. Six to eight weeks is realistic for a practice of any complexity. Reduce your schedule, don't pretend you can run full volume through a brand new system on day one. The practices I've seen fail at migration are almost always the ones that refused to protect the first month.

What to ask your next vendor before you sign

Portability cuts both ways. The reason you're moving is probably that your current vendor made leaving painful. Don't sign a new contract that recreates the trap.

Ask the new vendor for a sample export in the format they'd give you if you left tomorrow. Ask what it would cost. Ask whether their data model is documented publicly. Ask whether you can get read-only database or API access during your contract. The answers tell you how they think about ownership. If you want to see how we approach this on the infrastructure side, talk to our team; we built Qintara partly because we got tired of migrations where the outgoing vendor held the data hostage.

Frequently Asked Questions

How long does a realistic EMR migration take?

For a single-location practice with one specialty and clean-ish data, three to four months from contract signature to go-live is reasonable. Multi-location practices or compounding operations with pharmacy integrations should plan on six to nine. The extraction and mapping work is usually the long pole, not the new system configuration.

Should we migrate historical notes as structured data or PDFs?

Mostly PDFs, attached to the patient chart and tagged by date and encounter type. Structured migration of free-text notes rarely produces a result clinicians trust, and the cost is high. Keep structured migration for discrete data: meds, allergies, problems, labs, vitals. Older encounter notes as searchable PDFs is a sensible compromise most clinics land on.

What happens if we discover data problems after go-live?

Assume you will. Keep the old system in read-only access for at least 90 days, maintain the raw extract files in secure storage indefinitely, and designate someone as the data triage lead for the first quarter after cutover. Most issues can be resolved with a targeted re-pull from the archive rather than a wholesale re-migration.

Do we need a dedicated migration vendor or can the new EMR handle it?

Depends on complexity and on the new vendor's track record. Ask for references from practices with similar size and specialty, and ask those references specifically about the migration experience, not the ongoing use. If the new vendor's answers get vague when you push on extraction and mapping, bring in a specialist. The cost of a good migration partner is almost always less than the cost of a bad migration.