Data migration is where EMR projects quietly succeed or fail. Move too much and you import years of garbage; move too little and clinicians can't trust the chart on day one. The goal is a defensible, validated transfer of the data that matters — and a clear, accessible archive for the rest. Because migration touches every patient record at once, it tends to be both the most invisible part of an implementation and the part most likely to undermine confidence if it goes wrong. A chart that's missing an allergy or shows a duplicate medication erodes trust faster than almost any other go-live problem, and that trust is hard to win back.
Decide what actually migrates
You rarely need to bring everything forward. Categorize legacy data and assign each category a disposition.
| Data type | Typical approach |
|---|---|
| Demographics, insurance | Migrate (structured, high reuse) |
| Active problems, meds, allergies | Migrate (clinical safety) |
| Recent labs, immunizations | Migrate or interface |
| Old scanned documents | Archive or selective migrate |
| Historical encounter notes | Archive / read-only legacy access |
A common pattern is to migrate discrete, structured, clinically active data and keep the legacy system available read-only for historical detail. The reason is practical: structured data like an active problem list or a current medication list is what clinicians need at the point of care, while a decade of narrative progress notes is rarely consulted and migrates poorly. Bring forward what supports the next visit, and make the rest retrievable without cluttering the new chart.
Map fields before you move anything
Build a field-level mapping document: source field, target field, transformation rules, and code-set translations (for example, mapping legacy problem codes to current ICD-10-CM or SNOMED CT, and medications to RxNorm). Discrete data migrates cleanly only when both systems agree on the vocabulary. This mapping work is unglamorous and time-consuming, but it is the single highest-leverage activity in the whole migration — a wrong mapping silently corrupts thousands of records at once. Pay particular attention to free-text or locally invented codes in the legacy system, which often have no clean equivalent and need human decisions about how they translate.
Test with iterative loads
- Run a small pilot migration (for example, a few hundred patients) before the full load.
- Validate record counts, then spot-check fields against the source.
- Have clinicians review sample charts for real-world usability, not just technical accuracy.
- Repeat with progressively larger loads, fixing mapping errors each cycle.
Iterative loads matter because the first pass almost always surfaces mapping gaps you couldn't predict from the spec alone. Treat each cycle as a chance to find and fix problems while the stakes are low, rather than discovering them in production. Involving real clinicians in the review is essential: a migration can be technically flawless and still be unusable if active problems land in a section nobody looks at.
Reconcile and validate
Protect data in transit and at rest
Migration files often contain large volumes of PHI in a single, portable package — which makes them an attractive target and an easy thing to mishandle. Encrypt extracts, restrict who can access them, transfer over secure channels, and securely delete working copies when finished. Avoid emailing extracts or leaving them on shared drives, and keep a record of where every copy lives so none are orphaned. NIST's guidance for implementing the HIPAA Security Rule (SP 800-66r2) is a useful reference for safeguarding electronic PHI during projects like this.
Plan the legacy system's fate
- Confirm your record-retention obligations before decommissioning anything.
- Keep the old system accessible (read-only) or produce a complete export/archive.
- Verify the archive is searchable and that staff know how to retrieve from it.
- Document the cutover date so it's clear where each record lives.
Treat migration as its own sub-project with a mapping spec, a test plan, and a validation sign-off. The practices that do this rarely get the dreaded "the chart is wrong" calls on go-live day.