Here is the honest answer most vendors soften: when you switch EHRs, you will not get all of your data into the new system, and you should not try to. A realistic migration moves a defined slice of structured clinical data, converts some documents, leaves the rest behind in a readable archive, and accepts that a chunk of history will only ever be reachable by looking it up. Planning around that reality is the difference between a rough quarter and a genuine patient-safety problem.
What migration actually means
"Data migration" gets used to describe three quite different activities, and conflating them is where projects start to drift:
- Conversion — automatically mapping structured data from the old system's fields into the new system's fields.
- Abstraction — a human reading the old chart and re-entering key facts into the new one.
- Archival — keeping the legacy data accessible for lookup without bringing it into the new system at all.
Every real migration is a mix of all three. The strategic question is not "how do we move everything?" but "what belongs in each bucket?"
Discrete data versus documents
The single most useful distinction in this whole exercise: discrete data lives in a defined field with a defined meaning — a medication with a dose and an RxNorm code, an allergy with a reaction, a lab result with a value and units. Document data is a blob: a scanned referral, a signed consent, a PDF of an old note.
Discrete data can be mapped and converted, because the target system has a matching field. Documents can only be carried over as attached files — and a note that arrives as a PDF is no longer searchable, reportable, or usable for clinical decision support. It is a picture of information, not information.
What usually moves and what usually doesn't
| Data | Typical treatment | Why |
|---|---|---|
| Demographics, insurance | Converted | Well-structured, high volume, easy to map |
| Problem list, allergies, medications | Converted or abstracted | Safety-critical; must be discrete and current |
| Immunizations | Converted | Coded and reportable |
| Recent lab and imaging results | Converted, often a limited window | Trending matters; ancient results rarely do |
| Historical clinical notes | Documents, or left in archive | Free text rarely maps cleanly to a new schema |
| Scanned files | Attached as documents | Already blobs; nothing to map |
| Open orders, referrals, recalls | Abstracted, or run down before cutover | These are commitments, not history — losing them harms patients |
| Financial history, old claims | Usually stays in the legacy system | Rarely worth converting; needed for lookup and audit |
| Audit logs | Stays in the legacy system | Not clinically usable; retained for compliance |
The abstraction decision
Abstraction is manual, expensive, and the part everyone underestimates. It is also the part that most protects patients, because a human decides what is still true. An old medication list converted verbatim carries every drug the patient stopped taking in 2019; an abstracted list carries what they take now.
Practical approaches, roughly in order of cost:
- Abstract at the point of the first visit. Charts get abstracted only when the patient actually comes in, by staff who are already reviewing the chart. Low cost, spreads the work, but the first weeks after cutover are slow.
- Pre-abstract active patients. Define "active" (seen in the last 18–24 months, say), and work through that list before go-live. More upfront effort, far smoother launch.
- Abstract everything. Almost never worth it. Most of a chart is history no one will read again.
Whichever route, write down the abstraction standard: exactly which fields get carried forward, by whom, and verified against what. "Use your judgment" produces thirty different charts.
Keeping the old system readable
You cannot simply switch the legacy system off. You will need the historical record for clinical lookup, for billing follow-up, for audits, and for records requests — and records requests do not stop because you changed software.
Options are typically: keep the legacy system running in read-only mode (predictable, but you keep paying for it), or export to a third-party archive (cheaper long-term, but the export has to be complete and usable). Whichever you choose, decide it before you sign the new contract, because it changes the cost comparison.
Two frequently confused points on retention. Medical-record retention periods for the chart itself are largely set by state law and by payer and program requirements — not by HIPAA. HIPAA's own six-year documentation retention requirement applies to things like policies, procedures, and required records under the Security Rule, not to the medical record. Look up both before you decide what an archive has to hold and for how long.
The contract clauses that decide your fate
Your ability to leave a system is determined years earlier, in the contract you signed to join it. Before you sign with the new vendor, settle:
- Data ownership. Say plainly, in writing, that the practice owns its data.
- Export rights and format. Not just "we'll provide an export" — specify the format, the scope, and the timeframe. A PDF dump of every chart is technically an export and practically useless.
- Export cost. Fix it now. A vendor with no cap on extraction fees has enormous leverage over you at exactly the moment you want to leave.
- Transition assistance. Define what help you get, for how long, after you give notice.
- Certification. ONC's Health IT Certification Program includes criteria covering export of electronic health information. Check the product's listing on the Certified Health IT Product List and confirm what it's certified for.
It is also worth knowing that the federal information blocking rules apply to health IT developers of certified health IT and to health care providers. Practices that make it unreasonably hard to get electronic health information out — and vendors that do the same — are operating in a regulated space, not a purely commercial one.
A realistic sequence
- Inventory. What data exists, where, in what form, and who depends on it.
- Scope. Decide the convert / abstract / archive split, and write it down. This is the plan.
- Mapping. Match every source field to a target field. Unmapped fields are decisions, not accidents — log each one.
- Test migration. Load a sample into a test environment. Not a demo — your real data.
- Validate. Clinicians check charts they know. See below.
- Correct and re-run. Expect at least two rounds.
- Final load and cutover. Freeze the old system, run the final delta, go live.
- Archive and reconcile. Confirm the legacy record is readable before anyone celebrates.
Validate before you flip the switch
Validation is not a spot check by the project manager. It's clinicians opening charts of patients they know well and confirming the record still tells the truth. Build the check around questions with right answers:
- Does the medication list match what the patient is actually taking?
- Did every allergy come across — with its reaction, not just the substance?
- Are result values attached to the right dates, with the right units?
- Did any date shift? Time zone and date-format errors are quietly common.
- Are duplicate patient records being created by the merge?
- Do open orders, referrals, and recalls still exist?
Sample deliberately: complex chronic patients, pediatric charts, patients with long histories, patients with similar names. Simple charts always migrate fine and tell you nothing.
Where migrations go wrong
The recurring failure patterns are boring and predictable, which is good news — you can plan around them. Scope creep, as "let's just bring over one more thing" repeats until the timeline breaks. Silent truncation, where long free-text fields get cut off mid-sentence and nobody notices until a clinician reads half a note. Duplicate patients created by a sloppy merge. Discovering the export fee only after giving notice. And the quietest one: nobody was ever made accountable for confirming the legacy archive actually opens.
Assign that last job to a named person, with a date, before go-live. The day you need the old record is never a convenient day to discover it doesn't open.
Common questions
Can we migrate all of our historical data into the new EHR?
In practice, no. Structured data with a matching field in the new system can be converted; free-text notes and scanned files usually come across as documents or stay in a legacy archive. Trying to move everything typically adds cost without adding clinical value.
What is chart abstraction and do we need it?
Abstraction is a person reading the old chart and re-entering key facts, such as the current medication list, problem list, and allergies, into the new system. Most practices need some, because a verbatim conversion carries stale data forward as if it were current.
How long do we have to keep the old system's records?
Medical record retention periods are set mainly by state law and by payer and program requirements, not by HIPAA. HIPAA's six-year documentation retention rule applies to required policies and documentation, not to the medical record itself. Check both before decommissioning anything.
What should we negotiate now to make a future migration easier?
Data ownership stated in writing, a defined export scope and format, a capped or fixed export fee, and defined transition assistance after notice. These are far easier to secure before signing than at the moment you want to leave.