According to a March 2025 MGMA Stat poll, 23% of medical group practice leaders expect to switch or significantly update their EHR systems within the next 12 months. That is nearly one in four practices actively considering migration. Yet for most health systems, the mere thought of switching EHR vendors triggers a visceral reaction — not because the technology is difficult, but because the vendor lock-in makes leaving financially devastating.
In December 2025, Texas Attorney General Ken Paxton filed an antitrust lawsuit against Epic Systems, accusing the company of leveraging its control over 325 million patient records to block competition and restrict data access. The lawsuit alleges Epic imposes “massive penalty fees” on hospitals that attempt to use competitors’ solutions. This is not an abstraction — it is the reality of EHR migration in 2026.
This guide breaks down exactly why EHR migration costs so much, how FHIR-based data portability is changing the equation, and what you should demand from your vendor before signing your next contract.
The EHR Vendor Lock-In Problem (And Why It Costs $1B to Leave Epic)
EHR vendor lock-in is not a bug — it is a business model. The largest EHR vendors have built ecosystems designed to make switching prohibitively expensive. Here is how the economics work.
The Scale of Lock-In
Epic Systems controls approximately 42% of the U.S. hospital EHR market, with its database housing more than 325 million patient records — representing roughly 90% of all U.S. citizens, according to the Texas AG’s complaint. When a single vendor holds that much data, switching costs become astronomical.
Large health system implementations of Epic routinely cost between $100 million and $1 billion+. Sarasota Memorial Health Care projected a $160 million investment for their Epic implementation. Inspira Health budgeted $120 million. These are not technology costs alone — they include data migration, workflow redesign, training, interface rebuilding, and the productivity loss during transition.
The lock-in operates at multiple levels:
- Proprietary data formats: Epic uses Chronicles, a proprietary database architecture. Cerner (now Oracle Health) uses its own proprietary query language, CCL. Neither maps cleanly to standard formats without significant transformation.
- Contractual restrictions: As the Texas lawsuit alleges, vendors impose penalty fees on hospitals that attempt to use competitors’ solutions that rely on the hospital’s own EHR data.
- Integration dependency: After years of building interfaces, custom workflows, and third-party integrations around a specific EHR, the switching cost compounds well beyond the software itself.
- Network effects: Provider organizations that are not Epic customers are denied or delayed the ability to retrieve patient records, creating pressure for the entire care network to standardize on one vendor.
Why Traditional EHR Migration Is So Painful
A peer-reviewed study in Applied Clinical Informatics documented that EHR transitions are among the most complex and risky IT undertakings a healthcare organization can attempt. The pain concentrates in three areas.
Data Extraction Fees and Proprietary Barriers
For larger facilities transitioning from legacy EHRs, data migration costs alone can range from $50,000 to $250,000, according to industry cost analyses. But the financial pain extends far beyond the extraction itself:
- Exit fees: Many vendors charge per-record or flat-rate fees for data extraction. Some contracts include explicit “data extraction fees” that are separate from the migration itself.
- Format restrictions: Multiple practices have reported difficulty extracting their data when switching from vendors like eClinicalWorks, with data delivered in proprietary formats rather than standards like FHIR or C-CDA.
- Incomplete exports: Even when data is exported, critical elements like clinical notes, embedded images, scanned documents, and audit trails are often excluded or degraded.
- Timeline weaponization: Vendors have little incentive to expedite data exports for departing customers. Extraction timelines of 6–12 months are common, during which the organization continues paying maintenance fees.
Format Incompatibility and Data Mapping
Every EHR stores clinical data differently. A “problem list” in Epic is structurally different from one in Oracle Health or MEDITECH. This creates a mapping nightmare:
- Terminology mapping: Source systems may use SNOMED CT, ICD-10, or proprietary codes. The destination system may expect different code systems or granularity levels.
- Document structure: Clinical documents, care plans, and assessments are stored in vendor-specific templates that do not port cleanly.
- Historical data fidelity: Typically, only 1–2 years of clinical data is actively converted, with older data archived behind separate access protocols. This fragments the patient’s longitudinal record.
- Custom fields: Organizations spend years creating custom templates, flowsheets, and data fields. None of these survive migration without reconstruction.
Workflow Re-Training and Productivity Loss
The human cost is arguably the most painful. According to Healthcare IT Leaders, the most commonly underestimated costs are training, go-live support, and post-go-live optimization:
- Physician productivity drops 20–40% in the first 3–6 months after a major EHR switch.
- Training requirements: Clinicians need 16–40+ hours of training on new systems, pulled from clinical time.
- Workflow redesign: Every department’s clinical workflows must be rebuilt — order sets, clinical decision support rules, reporting dashboards, and quality metrics.
- Staff turnover: Major EHR transitions correlate with increased nursing and physician attrition, particularly among experienced clinicians resistant to learning new systems.
These factors explain why 83% of data migration projects fail or exceed budgets and timelines (Gartner). The current migration paradigm is broken.
How FHIR Data Portability Changes the Equation
The Fast Healthcare Interoperability Resources (FHIR) R4 standard, combined with regulatory mandates from CMS and ONC, is fundamentally restructuring how healthcare data moves between systems. This is not incremental improvement — it is a structural shift that directly attacks vendor lock-in.
FHIR Bulk Data Export ($export)
The FHIR Bulk Data Access specification (now at v3.0.0) defines a standardized mechanism for efficiently exporting large datasets. Here is what it enables for migration:
- System-level export:
GET [fhir-base]/$exportexports all data on the server in NDJSON (Newline Delimited JSON) format. - Patient-level export:
GET [fhir-base]/Patient/$exportexports all data for all patients. - Group-level export:
GET [fhir-base]/Group/[id]/$exportexports data for a specific cohort — useful for phased migrations. - Asynchronous processing: The server returns a
Content-LocationURL for polling status, then provides download links when the export completes. - Resource filtering: The
_typeparameter lets you request specific resource types (Patient, Condition, Observation, MedicationRequest) rather than everything at once.
The key advantage: NDJSON is a universal format. Unlike proprietary exports, any FHIR-compliant system can ingest these files directly. No custom mapping. No format conversion. No vendor-specific tooling required.
At Nirmitee, we build EHR integration solutions with FHIR data portability as a foundational requirement — not an afterthought. Every system we architect supports $export from day one, because we have seen firsthand how vendor lock-in traps health systems.
Patient Access API
The CMS Interoperability and Patient Access Final Rule requires Medicare Advantage organizations, Medicaid managed care plans, and QHP issuers to implement FHIR-based Patient Access APIs. Starting January 1, 2026, impacted payers must make all claims, encounter data, and clinical data (defined by USCDI v1) available through a standardized FHIR API.
For migration, this matters because:
- Patients can extract their own data in FHIR format from any compliant payer or provider.
- Third-party apps can aggregate patient data across multiple sources using SMART on FHIR authorization.
- Payer-to-payer exchange means clinical data follows the patient when they switch insurance, reducing gaps in longitudinal records.
System-Level Bulk Data and USCDI v3 Compliance
ONC’s HTI-1 final rule adopted USCDI v3 as the new baseline for certified health IT. By January 1, 2026, certified EHR systems must accommodate USCDI v3 data using FHIR US Core profiles. By July 4, 2026, health information networks must expose data via FHIR APIs aligned with US Core Implementation Guide and USCDI v3.
USCDI v3 includes 20+ data classes covering:
- Patient demographics, problems, medications, allergies, procedures, lab results
- Clinical notes (progress notes, discharge summaries, consultation notes)
- Social determinants of health (SDOH) data
- Health insurance information
- Clinical tests and diagnostic imaging reports
This regulatory timeline means that by mid-2026, every certified EHR vendor must support standardized FHIR-based data extraction covering the vast majority of clinical data types. The vendor lock-in playbook of “proprietary formats only” is becoming legally untenable.
The FHIR Portability Checklist: 7 Questions for Your EHR Vendor
Before signing or renewing any EHR contract, use this checklist to assess your data portability position. Every “no” answer represents a lock-in risk.
| # | Question | What “Good” Looks Like | Red Flag |
|---|---|---|---|
| 1 | Do you support FHIR R4 Bulk Data Export ($export)? | Full $export at system, patient, and group levels with NDJSON output | “We support data export” (without specifying FHIR format) |
| 2 | What data formats are available for extraction? | FHIR R4 NDJSON, C-CDA, CSV with complete data dictionaries | Proprietary format only, or “we will provide a data extract” |
| 3 | What are your data extraction and exit fees? | Zero additional fees; extraction included in license | Per-record fees, flat extraction fees, or “contact sales for pricing” |
| 4 | Is full API access included in our license? | Unrestricted FHIR API access for all licensed data | API access as paid add-on, rate-limited, or read-only |
| 5 | Are you USCDI v3 compliant for all data classes? | Full USCDI v3 support including SDOH and clinical notes | USCDI v1 only, or “on our roadmap” |
| 6 | Can patients download their complete record via Patient Access API? | SMART on FHIR-enabled patient portal with full data access | PDF export only, or limited data categories |
| 7 | What is your migration support SLA and timeline commitment? | Defined SLA with maximum extraction timeline (e.g., 90 days) | No SLA, no committed timeline, or “best effort” |
Scoring:
- 5–7 “Good” answers: FHIR-ready vendor. Low portability risk.
- 3–4 “Good” answers: Negotiate improvements before signing. Get commitments in writing.
- 0–2 “Good” answers: High vendor lock-in risk. Consider alternatives or negotiate hard on data portability clauses.
Migration Architecture: FHIR-Based Data Transfer
A FHIR-based migration follows a fundamentally different architecture than traditional approaches. Instead of a monolithic data dump followed by months of custom mapping, FHIR enables an incremental, standards-based transfer.
Traditional Migration Architecture (18–24 Months)
- Planning & Assessment (3 months): Inventory source system data, map to destination schema, identify gaps.
- Data Extraction & Custom Mapping (6 months): Extract from proprietary format, build custom ETL pipelines, transform to destination format.
- Custom Interface Development (4 months): Rebuild every third-party integration from scratch.
- Testing & Validation (3 months): Verify data integrity, clinical accuracy, and regulatory compliance.
- Training & Go-Live (4 months): Retrain all clinical and administrative staff.
- Post-Go-Live Stabilization (4 months): Fix data issues, optimize workflows, address user complaints.
FHIR-Based Migration Architecture (6–12 Months)
- FHIR Capability Assessment (2 months): Audit source and destination $export capabilities, identify USCDI coverage gaps, plan resource mapping.
- Automated FHIR Export (2 months): Execute $export operations, validate NDJSON output, run data quality checks against US Core profiles.
- FHIR Resource Mapping (2 months): Map FHIR resources from source to destination profiles. Because both sides speak FHIR, this is profile alignment, not format conversion.
- Validation & Testing (2 months): Automated FHIR validation tools verify resource conformance. Significantly faster than manual data checking.
- Training & Go-Live (2 months): Training still required for UI differences, but data is already structured identically.
- Stabilization (2 months): Shorter because data integrity issues are caught earlier by FHIR validation.
The Technical Architecture
A FHIR-based migration pipeline looks like this:
Source EHR Migration Pipeline Destination EHR
┌─────────────┐ ┌──────────────────┐ ┌──────────────┐
│ $export │──NDJSON──▶ │ FHIR Validator │ │ FHIR Server │
│ (Bulk Data) │ │ (US Core check) │ │ ($import or │
│ │ │ │ │ Bundle POST)│
│ Patient │ │ Profile Mapper │──FHIR R4──▶ │ │
│ Condition │ │ (source→dest │ │ Patient │
│ Observation │ │ profile align) │ │ Condition │
│ Medication │ │ │ │ Observation │
│ Encounter │ │ Reference Fixer │ │ Medication │
│ ... │ │ (update refs to │ │ Encounter │
│ │ │ new IDs) │ │ ... │
└─────────────┘ └──────────────────┘ └──────────────┘Key pipeline components:
- FHIR Validator: Checks every exported resource against US Core profiles. Catches data quality issues before they reach the destination.
- Profile Mapper: Aligns source FHIR profiles to destination profiles. This is dramatically simpler than proprietary-to-proprietary mapping.
- Reference Fixer: Updates internal references (e.g.,
Observation.subjectpointing toPatient/old-id) to use new resource IDs in the destination system. - Incremental Sync: Because $export supports
_sinceparameter, you can run incremental updates during the transition period, keeping both systems in sync.
This is the architecture pattern Nirmitee uses when building EHR solutions and migration tooling for our clients. By designing for FHIR portability from the start, we ensure that our clients are never locked into our platform — or anyone else’s.
Case Study: What Oracle Health’s Customer Exodus Teaches Us
The most dramatic real-world demonstration of EHR migration dynamics is unfolding right now with Oracle Health (formerly Cerner).
The Numbers
According to a August 2025 KLAS Research report, Oracle Health has lost 57 unique acute care customers since its acquisition of Cerner in 2022. Of these, 12 are large health systems with more than 1,000 beds. In 2024 alone, Oracle Health lost 74 hospitals and 17,232 beds, while Epic gained 176 facilities and 29,399 beds.
Major departures include:
- Intermountain Health — one of the largest health systems in the western U.S.
- UPMC — a $26 billion integrated delivery system.
- Henry Ford Health — a major Michigan health system.
- Adventist Health, ChristianaCare, Northwell Health — all signed deals to replace Oracle Health.
Oracle Health’s acute care EHR market share declined from 25% in 2021 to 22.9% in 2024. Perhaps most damning: 50% of interviewed customers said they would not repurchase the EHR today.
What This Teaches About Migration
The Oracle Health exodus reveals several migration realities:
- Switching is happening regardless of cost. Even when migration costs hundreds of millions, organizations will leave if the platform does not meet clinical needs. The 57 departures prove that lock-in has limits.
- The destination is almost always Epic. This creates a new form of market concentration. FHIR-native alternatives that reduce switching friction could capture some of this migration demand.
- Migration timelines are measured in years. Most of these health systems announced their departures in 2023–2024 but are still mid-migration in 2026. A FHIR-based approach could compress these timelines significantly.
- Data portability is the leverage point. Organizations with better data export capabilities and FHIR-ready architectures have an easier migration path. Those trapped in proprietary formats face the longest, most expensive transitions.
The Lesson for Smaller Organizations
If a $26 billion health system like UPMC faces a multi-year, multi-hundred-million-dollar migration, imagine the relative impact on a 50-physician practice group. For smaller organizations, vendor lock-in is not just expensive — it can be existential. FHIR data portability is disproportionately valuable for mid-market and smaller organizations that cannot absorb nine-figure switching costs.
Regulatory Tailwinds: Why FHIR Portability Is Becoming Mandatory
The regulatory landscape is accelerating FHIR adoption in ways that directly benefit migration scenarios:
- CMS-0057-F (January 2026): Payers must implement Patient Access, Provider Access, and Payer-to-Payer FHIR APIs. Compliance dates for API requirements begin January 1, 2027.
- ONC HTI-1 (January 2026): Certified health IT must support USCDI v3 via FHIR US Core profiles.
- TEFCA (Active): The Trusted Exchange Framework and Common Agreement enables nationwide FHIR-based health information exchange through Qualified Health Information Networks (QHINs). Learn more in our comparison of India’s ABDM vs. U.S. TEFCA.
- 21st Century Cures Act — Information Blocking: Providers and health IT developers that engage in information blocking face penalties. Refusing to support FHIR-based data extraction could constitute information blocking.
- Texas AG v. Epic (December 2025): If successful, this antitrust action could set precedent requiring dominant EHR vendors to make data extraction easier and cheaper.
Together, these regulations create a clear trajectory: within 12–18 months, every major EHR vendor will be required to support standardized FHIR-based data access. The question is whether your organization is positioned to leverage these capabilities when you need to migrate.
Building for Portability: What FHIR-Native EHR Architecture Looks Like
For organizations building new EHR systems or evaluating replacements, FHIR-native architecture eliminates migration pain by design. Here is what that means in practice:
- FHIR as the internal data model: Store clinical data as FHIR resources natively, not as proprietary objects that must be translated. This eliminates the export-transform-load pipeline entirely.
- $export built in from day one: Bulk Data Access is not an add-on — it is a core capability of the FHIR server.
- SMART on FHIR authorization: Standard OAuth 2.0 authorization means third-party apps work without custom integration. Our SMART on FHIR implementation guide covers this in detail.
- US Core profile conformance: Every resource conforms to US Core profiles from the start, ensuring USCDI v3 compliance and interoperability with any other conformant system.
- Open API architecture: Full HL7 and FHIR API access included — not a paid add-on or rate-limited afterthought.
This is the architecture philosophy behind Nirmitee’s healthcare platform engineering work. We believe that if you build a great product, you should not need vendor lock-in to retain customers. Data portability should be a feature, not a threat.
Conclusion: Your Migration Does Not Have to Cost $1 Billion
EHR migration in 2026 does not have to follow the traditional playbook of multi-year timelines, nine-figure budgets, and organizational trauma. FHIR R4, Bulk Data Export, regulatory mandates, and USCDI v3 are converging to create a standards-based migration pathway that dramatically reduces cost and complexity.
Here is what you should do now:
- Audit your current vendor using the 7-question portability checklist above. Know exactly where you stand.
- Negotiate FHIR portability into your next contract. Require $export support, zero exit fees, and defined extraction SLAs in writing.
- Build a FHIR data inventory. Map your clinical data to USCDI v3 data classes. Identify gaps in FHIR coverage now, before you need to migrate.
- Test $export today. If your vendor claims to support Bulk Data Export, test it. Export a subset of data and verify it is valid FHIR. Do not wait until migration day to discover it does not work.
- Evaluate FHIR-native alternatives. If you are considering a switch, prioritize vendors that store data as FHIR natively. Your future exit will be a non-event rather than a crisis.
The organizations that thrive in the next decade of healthcare IT will be those that own their data, not those who rent access to it from their EHR vendor. FHIR data portability is the key to making that a reality.
Need help with EHR migration planning, FHIR integration, or building interoperable healthcare systems? Talk to Nirmitee’s healthcare engineering team — we build with portability by design.
Building interoperable healthcare systems is complex. Our Healthcare Interoperability Solutions team has deep experience shipping production integrations. We also offer specialized Custom Healthcare Software Development services. Talk to our team to get started.
