EHR Data Migration: A Complete Planning and Risk Management Guide (2026)

Data Migration vs. Data Conversion: Know the Difference

These terms are used interchangeably in casual conversation, but they describe different processes — and confusing them leads to misscoped projects and missed requirements.

Data migration is the process of moving information from one system to another with validation steps to confirm accurate transfer. The data's format and structure stay essentially the same. Think of it as moving boxes from one warehouse to another — the contents don't change, just the location.

Data conversion adds a critical transformation step. The data is not only moved but reformatted to match the destination system's structure. A patient's allergy code in System A might need to map to a completely different coding scheme in System B. This is where complexity — and risk — escalate dramatically.

In practice, most EHR transitions require both. Structured clinical data (problem lists, medications, demographics) must be converted to fit the new EHR's schema. Documents, images, and scanned records are typically migrated as-is into a document management system or archive. Large health systems routinely deal with 30-40+ legacy applications requiring some combination of conversion, migration, or decommissioning.

Understanding this distinction upfront is essential because it determines your project scope, timeline, vendor requirements, and testing strategy. If your implementation plan doesn't distinguish between data that needs conversion and data that needs simple migration, you're already behind.

The PAMI+P Data Framework: What to Migrate First

Not all data is created equal. In EHR migrations, the industry has converged on a prioritization framework known as PAMI+P — the five categories of clinical data that clinicians need immediate access to in the new system:

• Problems — Active diagnoses and the problem list. This drives clinical decision-making, care plans, and billing.
• Allergies — Drug allergies, food allergies, and environmental sensitivities. Critical for patient safety and drug-drug interaction alerts.
• Medications — Active prescriptions, dosages, frequencies, and prescribing providers. Errors here have direct patient safety implications.
• Immunizations — Vaccination history, particularly important for pediatric practices and public health reporting.
• Procedures — Surgical history, major procedures, and relevant clinical events that inform future treatment decisions.

The standard practice is to migrate 18-24 months of PAMI+P data into the new EHR as structured, searchable, actionable records. Data older than this window is typically archived — not discarded — in a read-only system for compliance and reference.

Beyond PAMI+P: The Full Data Picture

PAMI+P is the minimum viable migration. Depending on your specialty and workflows, you may also need to convert:

• Patient demographics — Name, DOB, address, insurance, emergency contacts, preferred language
• Lab results — Recent lab values that inform ongoing treatment (typically 12-24 months)
• Vital signs — Baseline measurements for chronic disease management
• Upcoming appointments — Active scheduling data and referral queues
• Clinical notes — Recent progress notes, often migrated as PDFs or C-CDA documents rather than converted to discrete data
• Billing history — Open claims, payment plans, and authorization records
• Documents and images — Scanned consent forms, referral letters, diagnostic images (X-rays, MRIs)

Structured vs. Unstructured Data: Two Different Problems

A legacy EHR contains layers of both structured and unstructured data — and they require fundamentally different migration strategies.

Structured Data

Structured data lives in defined fields with consistent formatting: demographics, medications in an RxNorm-coded list, lab results with LOINC codes, problem lists using ICD-10 or SNOMED CT. This data can be mapped field-to-field between systems — but the mapping is rarely one-to-one.

Different EHR systems use different internal coding schemes, database structures, and data models. An allergy recorded as a free-text entry in one system needs to map to a coded, structured allergy record in another. A medication dosage stored in milligrams in one system might be stored with a different unit convention in the new system. These discrepancies are where conversion errors — including the documented case of a medication dosage being doubled during conversion — originate.

Unstructured Data

Unstructured data includes free-text clinical notes, scanned documents, patient communications, faxes, and handwritten records that were digitized. This data is far harder to convert because it lacks the discrete, coded structure that enables field-to-field mapping.

The practical approach for unstructured data is typically one of three strategies:

1. Migrate as documents — Move clinical notes as PDF or C-CDA documents attached to the patient chart in the new system. Searchable but not structured.
2. Archive in a read-only system — Move to a separate legacy archive accessible via single sign-on from the new EHR.
3. NLP extraction — Use natural language processing to extract discrete data points from free-text notes. Promising but still limited in accuracy for complex clinical narratives.

HIPAA Compliance During Data Migration

Every EHR data migration involves moving protected health information (PHI) — which means HIPAA's Security Rule, Privacy Rule, and Breach Notification Rule apply at every stage. This isn't optional, and violations during migration carry the same penalties as any other HIPAA breach: up to $2.13 million per violation category per year.

Business Associate Agreements: The Foundation

Every vendor that touches PHI during migration must have a signed BAA. This includes:

• The new EHR vendor receiving the data
• Any third-party migration specialists or consultants
• Data archival providers hosting legacy records
• Cloud infrastructure providers (AWS, Azure, GCP)
• Interface engine vendors facilitating data transfer

The BAA defines responsibilities for safeguarding PHI, breach notification timelines, encryption requirements, and what happens to data after the engagement ends. Without a BAA, your organization bears full liability for any breach that occurs during migration — even if caused by the vendor.

Encryption Requirements

HIPAA requires that data be rendered "unusable, unreadable, or indecipherable to unauthorized individuals." In practical terms:

• Data at rest — AES-256 encryption is the industry standard. All migration staging environments, temporary storage, and backup copies must be encrypted.
• Data in transit — TLS 1.2 or higher for all data transfers. Never send PHI over unencrypted channels, even within your internal network during migration.
• Portable media — If any data is transferred via physical drives (still common in large migrations), those drives must use hardware-level encryption.

Audit Logging and Access Controls

Maintain detailed audit logs for every data access event during migration — who accessed the data, when, what they did, and from where. This isn't just good practice; it's a HIPAA requirement and your primary evidence trail if something goes wrong.

Apply the Minimum Necessary Standard: only the data essential for migration should be accessed or transferred. Migration team members should have role-based access limited to their specific responsibilities — the database engineer doesn't need access to clinical notes, and the training team doesn't need access to the production migration database.

Risk Assessment and Documentation

Conduct a HIPAA Security Risk Assessment before migration begins. Document your migration procedures, security controls, testing protocols, and any incidents. This documentation is mandatory and must be retained for six years. If HHS investigates a breach that occurred during or after migration, this is the first thing they'll ask for.

FHIR and USCDI: Standards That Shape Your Migration

If you're migrating in 2026, two regulatory standards directly affect what data formats your new system must support — and how your migration needs to be structured.

USCDI v3: Mandatory Since January 2026

The United States Core Data for Interoperability Version 3 (USCDI v3) became the mandatory baseline for certified health IT on January 1, 2026. It encompasses 16 data classes and nearly doubles the number of required data elements from the original USCDI v1.

Key additions in v3 that affect migration planning:

• Health Status/Assessments — New data class including disability status, mental/cognitive status, functional status, and pregnancy status
• Health equity data — Sexual orientation, gender identity, and social determinants of health now have standardized data elements
• Expanded clinical data — Additional structured elements for labs (LOINC), medications (RxNorm), and conditions (SNOMED CT)

If your legacy EHR doesn't capture these data elements in structured form — which many older systems don't — your migration is also an opportunity to establish the data infrastructure your organization will need going forward.

FHIR API Requirements: July 2026 Deadline

By July 4, 2026, certified health IT must expose data via FHIR APIs aligned with the US Core Implementation Guide and USCDI v3. This means your new EHR system must share patient records in real time using the HL7 FHIR R4 standard.

For migration, this has practical implications:

• FHIR as a migration tool — Some organizations are using FHIR APIs to extract data from legacy systems, particularly for structured clinical data. This approach can simplify mapping if both systems support FHIR.
• C-CDA to FHIR transition — The HTI-5 proposed rule signals a move away from C-CDA-dependent capabilities toward FHIR-first interoperability. If your legacy system exports in C-CDA format, your migration plan should account for the transformation to FHIR-compatible structures.
• Vendor evaluation — When selecting a new EHR, verify that it has production-ready FHIR R4 APIs. This is no longer a nice-to-have; it's a regulatory requirement. See our cloud vs. on-premise comparison for how deployment model affects FHIR readiness.

Migration Approaches: Big-Bang vs. Phased

There are two fundamental strategies for cutting over to a new EHR system, and the choice has significant implications for risk, cost, and operational disruption.

Big-Bang Migration

In a big-bang approach, the entire organization switches from the old system to the new system over a single cutover weekend — typically Friday evening through Monday morning. All data is migrated in one pass, and Monday begins with everyone using the new EHR.

• Advantages: Clean break from legacy system, no parallel system maintenance, shorter total project timeline, single training push
• Risks: Higher stakes if something goes wrong, more intensive go-live support needed, greater initial disruption to workflows
• Best for: Small to mid-size practices, single-site organizations, organizations with strong vendor support commitments

Phased Migration

In a phased approach, the organization migrates in stages — by department, location, data type, or patient population. Some parts of the organization are on the new system while others remain on the legacy system.

• Advantages: Lower risk per phase, lessons learned from early phases improve later ones, less operational disruption at any given moment
• Risks: Extended timeline increases total cost, parallel system operation creates complexity, data synchronization between old and new systems during overlap
• Best for: Large health systems, multi-site organizations, organizations with low risk tolerance or limited go-live support resources

Cutover Weekend Planning

Regardless of approach, the actual data cutover should be scheduled during a period of low clinical volume. Best practices:

• Avoid month-end or quarter-end — Billing, reporting, and quality submissions create competing demands on staff attention.
• Avoid holiday periods — Key personnel must be available for the full cutover and immediate post-go-live support.
• Run at least two test migrations before the production cutover — this validates your timeline estimates, identifies mapping issues, and builds team confidence.
• Budget a 20-30% time buffer — Measure data throughput (records per second) during test runs and add buffer for production-day surprises.
• Implement a data freeze — Stop making changes to the legacy system 24-48 hours before cutover to prevent last-minute sync issues.

Testing and Validation: Where Most Migrations Fail

Testing is the single most important safeguard against migration failure — and it's the phase that gets shortchanged most often when timelines slip. According to Gartner, 83% of data migration projects fail or exceed their budgets, and inadequate testing is a primary contributor.

The Five Layers of Migration Testing

1. Record count validation — Compare the number of records in each source table against the number in the destination. If you started with 50,000 patient records, you should end with 50,000 patient records. Any discrepancy signals data loss or duplication. This is your first and fastest sanity check.
2. Data integrity checks — Beyond counts, verify that the actual content is correct. Run checksums on key fields. Compare aggregate values (total medication records, total lab results) between source and destination. Spot-check a random sample of individual records — verify that John Smith's medication list in the new system matches his medication list in the old system.
3. Mapping validation — Confirm that coded data was mapped correctly. Did the allergy to penicillin map to the right allergy code? Did the ICD-10 diagnosis code translate correctly? This requires clinical review, not just technical verification.
4. Functional testing — Verify that the migrated data actually works within the new system. Can you generate a Continuity of Care Document (CCD) for a migrated patient? Do drug interaction alerts fire correctly against migrated medication lists? Does the problem list display properly in the patient chart?
5. User Acceptance Testing (UAT) — Clinicians walk through real-world scenarios using migrated data. They spot-check patient records they know well, verify that allergies and medications display correctly, and confirm that clinical workflows function as expected with the migrated data. UAT is your last line of defense before go-live.

Testing Best Practices

• Start with small samples — Migrate a subset (100-500 patients) first. This uncovers mapping errors without the time investment of a full migration.
• Test early and often — Don't save all testing for the week before go-live. Run test migrations throughout the project, ideally monthly during the data mapping phase.
• Involve clinicians early — Technical staff can validate record counts and data formats. Only clinicians can validate that the clinical content makes sense and is safe for patient care.
• Document everything — Track every issue found, how it was resolved, and verify the fix in the next test cycle. Maintain a formal testing log with sign-offs.
• Define acceptance criteria upfront — What percentage of records must pass validation to proceed? A common threshold is 99.5% for structured clinical data and 100% for medication and allergy records.

Patient Safety: The Stakes of Getting It Wrong

EHR data migration is not just an IT project — it's a patient safety event. Published research from PMC and the Journal of Patient Safety documents real incidents where migration errors directly harmed patients or created conditions for harm.

Documented Patient Safety Risks

• Medication dosage errors — One documented incident involved a data conversion error that doubled a patient's medication dosage. Automated conversion can migrate structured data reliably, but discrepant data structures between systems can introduce life-threatening errors.
• Incomplete allergy transfers — In one case study, clinicians never updated patient allergies despite multiple post-transition appointments, because the incomplete migration created a false sense that the allergy list was complete.
• Reduced drug-drug interaction alerts — Partners Healthcare experienced markedly reduced drug-drug interaction alert effectiveness after an EHR vendor transition, because the new system's clinical decision support relied on data elements that didn't fully migrate.
• Legacy data access gaps — When clinicians can't access historical records from the old system during the transition period, they make clinical decisions with incomplete information. This is particularly dangerous for patients with complex medication histories or chronic conditions.
• Duplicate patient records — Healthcare organizations commonly discover duplicate record rates of 8-12%, far above the ideal 3% threshold. Migration can either fix this problem (through deduplication) or make it worse (by creating new duplicates during matching errors).

Safety Mitigation Strategies

• Clinician-led validation of all medication and allergy data before go-live — not just technical verification, but clinical review by physicians and pharmacists.
• Parallel legacy access — Maintain read-only access to the old EHR for at least 6-12 months post-migration so clinicians can cross-reference when migrated data seems incomplete.
• Medication reconciliation — Require a full medication reconciliation for every patient seen in the first 2-4 weeks post-go-live, regardless of whether they were recently reconciled in the old system.
• Enhanced clinical decision support — Verify that all CDS rules (drug interactions, allergy alerts, dosage range checks) are functioning correctly with migrated data before go-live.
• Incident reporting — Establish a dedicated channel for reporting migration-related clinical issues during the first 90 days. Treat every report with urgency.

These risks are not hypothetical. If your organization is approaching migration without a patient safety plan, review our guide to why EHR implementations fail for additional lessons from real-world failures.

Vendor Data Portability: Questions to Ask Before You Sign

Data portability — the ability to extract your data from one system and move it to another — varies dramatically between EHR vendors. The 21st Century Cures Act prohibits information blocking, but the practical reality of getting your data out of a legacy system can range from straightforward to nightmarish.

Before signing a contract with any EHR vendor (old or new), get clear answers to these questions:

1. What export formats does the system support? — At minimum, require C-CDA, CSV, and FHIR bulk data export. Proprietary-only exports are a red flag that will dramatically increase your future migration costs.
2. Is there an extraction fee? — Some vendors charge substantial fees for data extraction, particularly for historical data beyond a certain timeframe. Negotiate extraction terms into your contract upfront.
3. What is the data retention period after contract termination? — You need time to complete migration after you've stopped using the old system. Standard is 30-90 days; negotiate for 6 months if possible.
4. Will the vendor provide technical support during data extraction? — Schema documentation, API access, and technical support from the legacy vendor's team can make or break your migration timeline.
5. Does the contract include a data escrow clause? — If the vendor ceases operations, an escrow arrangement ensures you can still access your data.

Archiving Legacy Data: Don't Just Delete the Old System

After migration, you'll have data that wasn't converted to the new EHR — older clinical records, historical billing data, documents from inactive patients. You can't simply delete it: state retention laws typically require maintaining medical records for 7-10 years after the last patient encounter (longer for pediatric records). HIPAA doesn't set a specific retention period but requires that you follow applicable state laws.

Three Archival Strategies

1. Maintain legacy system in read-only mode — Keep the old EHR running but accessible only for viewing historical data. This is the simplest short-term solution but the most expensive long-term: you're paying for software licenses, server maintenance, and security patches on a system you're no longer actively using.
2. Migrate to a dedicated archive platform — Move legacy data to a specialized archival solution (MediQuant DataArk, Harmony HealthData Archiver, Access EHR Archive). These platforms provide searchable, read-only access to historical patient records, often with single sign-on from your new EHR. According to KLAS, 85% of organizations that moved from maintaining a legacy system to a dedicated archive reported a financial benefit.
3. Convert to a standard format and store — Export legacy data as C-CDA documents or PDF patient summaries and store them in a secure document repository linked to the new EHR. Less expensive than a dedicated archive but less functional for complex data queries.

Archive Access Requirements

Whatever approach you choose, your archive solution must provide:

• Read-only patient record access organized by patient chart
• HIPAA-compliant security controls (encryption, access logging, role-based permissions)
• Integration with your new EHR — ideally single sign-on or embedded access so clinicians don't need to log into a separate system
• Compliance with state medical record retention requirements
• The ability to produce records for legal discovery, audits, and patient requests

Frequently Asked Questions

Your Migration Action Plan

EHR data migration is one of the highest-risk, highest-stakes projects in healthcare IT. It touches patient safety, regulatory compliance, operational continuity, and financial performance simultaneously. But it's also a solvable problem — organizations complete successful migrations every day.

The difference between success and failure comes down to planning discipline:

1. Assemble your team early — Include clinical leadership (CMIO), health information management, IT, and project management. Engage cross-functional teams and external migration partners months before your planned go-live, not weeks.
2. Define your data scope — Use the PAMI+P framework. Decide what gets converted, what gets archived, and what gets left behind. Get clinical sign-off on this decision.
3. Inventory your legacy landscape — Count every system, interface, and data source. Large organizations commonly discover 30-40+ applications that need disposition planning.
4. Map, test, validate, repeat — Data mapping is where the real work happens. Budget at least two full test migrations before production cutover. Involve clinicians in validation from the first test cycle.
5. Plan for patient safety — Require medication reconciliation post-go-live, maintain legacy access, verify clinical decision support, and establish incident reporting.
6. Prepare for the productivity dip — Budget for a 10-25% temporary productivity decrease in the first 2-4 weeks. Reduce patient volume during go-live week.

For a complete phase-by-phase implementation planning guide, see our EHR Implementation Checklist. For understanding common failure patterns, read Why EHR Implementations Fail.