Migrating charts is the highest-risk part of switching EMRs. Get it wrong and clinicians lose access to history, billing breaks, and patient safety suffers. Get it right with a clear plan, validation at every step, and realistic expectations about what truly needs to move. Here is a practical sequence.
Step 1: Decide what to migrate
You rarely need to convert every field from the old system. Separate data into tiers: structured data that should migrate discretely, documents that can move as PDFs, and historical data that can stay in a read-only archive of the legacy system.
- Discrete migration: Demographics, allergies, medications, problem lists, immunizations
- Document migration: Scanned records, prior notes, imaging reports as files
- Archive only: Old data with low ongoing clinical value, retained for compliance
Step 2: Map the data
Build a field-by-field mapping between systems, paying special attention to coded data. Medications, problems, and allergies should map to standard terminologies (RxNorm, SNOMED CT, ICD-10) so they remain usable for decision support and reporting. Unmapped or mismatched codes are a common failure point.
Step 3: Test with a sample
Never migrate everything at once on the first try. Run a representative sample, then validate it carefully in the new system. Check that allergies still trigger interactions, medication lists are intact, and documents are attached to the correct patient.
Validation checklist
- Patient identity matches across systems (no merged or split records)
- Allergies and medications are present and coded correctly
- Problem lists and immunizations carried over
- Documents are legible and attached to the right encounter
- Counts reconcile: patients in equals patients out
Step 4: Plan the cutover
Decide on a go-live date and freeze window. Determine how to handle the gap between the last migration extract and go-live, often a manual catch-up of recent activity. Communicate the plan to clinical and front-office staff so nobody is surprised.
Step 5: Preserve the legacy system
Even after a clean migration, keep access to the old system, read-only if possible, for as long as your record-retention obligations require. Retention periods vary by state and payer, so confirm the requirement that applies to you before decommissioning anything.
Common pitfalls
- Underestimating data cleanup needed in the old system first
- Skipping reconciliation, then discovering missing patients weeks later
- Migrating free-text that should have been mapped to codes
- Decommissioning the legacy system before retention obligations are met
Treat migration as a project with its own plan, owner, and validation gates. The practices that struggle are the ones that treat it as an afterthought to the software purchase.
Who does the work
Migration involves three parties: the old vendor (who controls your data export), the new vendor (who receives it), and your own team (who decides what matters and validates the result). Sort out responsibilities early, especially with the outgoing vendor, who has little incentive to make leaving easy. Confirm in writing what data you can extract, in what format, and at what cost. Practices are sometimes surprised that their own data is hard or expensive to get out, which is exactly why exit and data-portability terms deserve attention when you first sign a contract, not when you leave.
Set expectations with clinicians
Clinicians often expect the new system to look exactly like the old one with every historical detail intact. It will not. Communicate clearly what is migrating discretely, what is available as a document, and what lives only in the read-only legacy archive, and explain why. Setting these expectations before go-live prevents the frustration and loss of trust that comes from a clinician searching for data that was never going to be there. A short orientation on where to find historical information pays off in the first chaotic weeks.