Preparing for an EHR migration
The difference between a smooth EHR migration and a painful one is almost entirely decided before anyone touches the data. Here is what to have ready.
The difference between a smooth EHR migration and a painful one is decided almost entirely before anyone touches the data. Gather these things first and the project shortens; discover them mid-conversion and it does not.
Decide what actually moves
The instinct is “everything”. That is usually the wrong answer — it is the most expensive option and it imports two decades of accumulated mess into a clean system. Sort your data into three buckets:
| Convert | Structured data the new system needs to work on day one: demographics, active problems, medications, allergies, immunisations, upcoming appointments, insurance, open balances. |
|---|---|
| Archive | Historical detail that must remain accessible but not necessarily live — closed encounters, old documents, inactive patients. A searchable read-only archive is far cheaper than conversion and usually satisfies both clinicians and retention rules. |
| Leave | Data with no clinical or legal value. Say so explicitly and record the decision — do not let it happen by omission. |
What you will be asked for
- Extract access to the legacy system — a database export, a documented API, or a vendor extract service. Confirm this before signing with the new vendor. Some legacy vendors charge substantially for extracts, or are slow, and that shapes the timeline more than anything technical.
- Data dictionary for the source system — what each table and field means. Beg for it. Reverse-engineering it is the single largest hidden cost in these projects.
- Your customisations. Custom fields, home-grown templates, local codes, that one workflow built around a spreadsheet. These have no automatic equivalent and each needs a decision.
- Your code sets — which versions of ICD, CPT and SNOMED you use, and any local codes that map to nothing standard.
- Interfaces you depend on — labs, imaging, e-prescribing, clearinghouse, patient portal, recall messaging. Each is its own small project, and lab interfaces are usually the long pole.
- Record counts — patients, encounters, documents, images. Volume drives both timeline and cost.
- A named decision-maker with authority to settle mapping questions quickly. Committees stall conversions.
Mapping is where the work is
Two systems never model data identically. Expect to spend real time on: fields that exist in one system and not the other; free text that needs to become structured; duplicate patient records that must be merged (nearly every practice has them); dates recorded ambiguously; and provider identifiers that changed over the years.
Validate in a way that would catch a real error
Reconcile counts
Patients in, patients out. Encounters, documents, allergies. Every discrepancy gets explained — not rounded away.
Have clinicians check real charts
Pick a sample including your most complex patients. A clinician opens the chart in the new system and confirms it tells the same story. Nothing substitutes for this.
Check the boundaries
Oldest and newest records, patients with unusual characters in their names, minors, deceased patients, patients with multiple insurers.
Test the money
Open balances, insurance details, claims in flight. Billing errors surface weeks later and are painful to unwind.
Rehearse the cutover
A full dry run against real data, timed. This tells you whether the switch fits in the weekend you have allocated.
Around go-live
- Reduce the schedule for the first week. Everyone is slower; pretending otherwise punishes patients and staff.
- Keep the legacy system readable for a defined period — and budget for it. Practices always need it longer than planned.
- Confirm your retention obligations before decommissioning anything.
- Put a BAA in place with the new vendor and anyone handling the conversion — see Business Associate Agreements.
- Have a rollback plan and the criteria that would trigger it, agreed in advance and in writing.
FAQ
How long does a migration take?
For a small practice with clean data and few interfaces, a few months. Multi-site, heavy customisation or a difficult legacy vendor pushes it considerably longer. The extract and the interfaces drive the schedule far more than the record count does.
Can we avoid downtime entirely?
Usually you can get it down to a planned weekend rather than eliminate it. The final delta — data created after the last full extract — has to move at a point when nobody is writing to the old system.
Our old vendor is being difficult about the extract.
Common, and worth escalating early. Your contract may specify data-return terms, and information-blocking rules constrain vendors more than they once did. Start this conversation months ahead — it is the most frequent cause of a slipped go-live date.