Migration is where EHR transitions succeed or fail

You can have the best EHR in the world. If the migration loses data, corrupts records, or takes too long, the clinic will never trust the new system.

Data migration is not a technical project. It is a clinical safety project with technical components.

The migration phases

Phase 1: Discovery and mapping

Before moving anything, you need to know:

  • What data exists in the source system
  • What format it is in
  • What data the destination system needs
  • What transformations are required

Common data categories:

  • Demographics and insurance
  • Problem lists and diagnoses
  • Medication lists (active and historical)
  • Allergies
  • Lab results and vital signs
  • Clinical notes and documents
  • Immunization records
  • Appointment history

Phase 2: Extraction

Getting data out of legacy EHRs is often the hardest part. Options:

  • CCDA export: Most EHRs can export patient summaries as CCDA documents. Coverage varies widely.
  • Database export: If you have direct database access, you can extract more completely. Requires deep knowledge of the source schema.
  • API extraction: Some EHRs offer FHIR or proprietary APIs. Often incomplete.
  • HL7 v2 feeds: ADT and results feeds can provide real-time data during a parallel-run period.

Plan for incomplete extraction. Every source system has data that does not export cleanly.

Phase 3: Transformation

Source data rarely matches destination format exactly. Common transformations:

  • Code system mapping (ICD-9 to ICD-10, local codes to standard terminologies)
  • Date format normalization
  • Provider identifier mapping (NPI, internal IDs)
  • Document format conversion (PDF, RTF, plain text)
  • Medication mapping (NDC to RxNorm)

Every transformation is a potential data quality issue. Validate aggressively.

Phase 4: Loading

Load data into the destination system in dependency order:

  1. Practice and provider setup
  2. Patient demographics
  3. Insurance and coverage
  4. Clinical data (problems, meds, allergies)
  5. Historical documents and notes
  6. Lab results
  7. Appointments and scheduling data

Phase 5: Validation

Validation is not optional. For every data category:

  • Compare record counts between source and destination
  • Spot-check individual records for accuracy
  • Verify critical data (allergies, active medications) with clinical staff
  • Test clinical workflows against migrated data

Phase 6: Parallel run

Run both systems simultaneously for a defined period. This:

  • Catches migration gaps before the old system is decommissioned
  • Gives staff a safety net
  • Provides time for data correction

The risks that matter

Silent data loss

Data that migrates but loses context. A medication without a dose. A lab without units. A diagnosis without a date. These are harder to detect than complete failures.

Referential integrity

Patient records that reference providers, locations, or orders that did not migrate correctly. Broken references create confusion and potential safety issues.

Historical continuity

Clinicians need longitudinal context. If historical data is incomplete or inaccessible, clinical decision-making degrades.

Staffing the migration

You need:

  • A clinical champion who validates data accuracy
  • A technical lead who manages extraction and loading
  • A project manager who tracks progress and risks
  • Staff time for validation (this is the most underestimated cost)

The standard to hold

If you cannot prove that every active medication, every allergy, and every active problem migrated correctly, you are not ready to go live. Patient safety is the acceptance criterion.