Cerner to Epic Migration: Cost, Timeline, and Data Steps (2026)

Posted in EPIC

A Cerner to Epic migration is an 18- to 36-month program that moves a health system’s patient data, HL7 interfaces, reports, and connected applications from Oracle Health Millennium to Epic. Publicly announced budgets run from $35 million for a three-hospital system to $660 million for a 52-hospital system. The patient data move is usually the smaller part of the work. The integration layer built around Cerner over a decade, which no EHR vendor contract covers, is what most programs underestimate. The market is moving in one direction. Epic holds 42.3% of US acute care hospitals after adding 176 hospitals and nearly 30,000 beds in 2024. This guide covers what a Cerner EMR migration includes, how Cerner data migration works step by step, and how the two data models differ. 

Cerner to Epic Migration Scope

A Cerner to Epic systems conversion has four workstreams, and only the first one is what people usually mean by migration.

Patient data migration moves clinical, financial, and administrative records from Millennium into Epic Chronicles and decides what is archived instead of converted. This is the workstream every implementation plan includes.

Interface rebuild covers every HL7 v2 feed Cerner sends or receives: 

• ADT
• Orders
• Results
• Charges
• Documents. 

Cerner interface configuration does not import into Epic Bridges. Each interface is rebuilt from the message definition up and tested against the receiving system.

Report conversion rewrites CCL, and Discern reports built against Millennium tables so they run against Clarity or Caboodle. Report-writing access in Cerner was rarely governed, so the production inventory is almost always larger than the one on paper.

Application re-certification covers SMART on FHIR and API-connected apps registered through Cerner’s developer program, which must be re-registered and tested against Epic’s FHIR endpoints. Oracle Health retired its DSTU2 FHIR APIs on December 1, 2025, so any application still on DSTU2 needs an R4 rebuild whether or not the hospital migrates.

Budgeting for the first workstream alone is the most common reason a Cerner to Epic migration runs over.

Cerner Data Migration Steps

Step 1: Database Backup Request

Extraction cannot start until Oracle Health delivers a full Millennium database backup. Request it at program kickoff and confirm encryption keys, delivery format, and any access fees in the same request, because each one can add weeks. A backup requested late is schedule compression later, in the phase where compression does the most damage.

Step 2: Extraction Method

Cerner CCL queries work for targeted pulls but are slow at billions of rows. For bulk extraction, most programs read the Oracle database directly through SQL against the delivered backup. Decide early which method each dataset uses, because the two produce different formats and need different validation.

Step 3: Data Classification

Sort records into three groups: active clinical data that must be live in Epic at go-live (problem lists, medications, allergies, immunizations, recent results); historical data needed for continuity of care (prior encounters, procedures, chronic condition history); and records kept only to meet retention law. State medical record retention periods vary widely, so legal and HIM sign-off belongs in this step, not after cutover.

Step 4: Field Mapping

Millennium stores data in relational Oracle tables. Chronicles is a hierarchical database organized around Epic’s own item identifiers. Map each discrete Cerner field to its Epic target, then handle non-discrete data (free-text notes, scanned documents) separately through C-CDA documents or document references. Custom Cerner fields and site-specific code sets are where mapping fails most often.

Step 5: Validation Cycles

Run at least three cycles: a small sample, a large sample, and a full-volume load, with reconciliation counts at source, staging, and target. Clinical reviewers should open converted charts and check them, because row counts do not catch a medication list loaded against the wrong encounter.

Step 6: Cutover and Archive

Load active data in the final pre-go-live window, run Epic and Cerner in parallel for a defined period, then move the remaining history into an archive clinicians can open from inside Epic. Decommissioning Cerner is the last step, and it is only possible if the retention decisions in Step 3 were made.

 

Cerner to Epic Migration Framework Stages

Stage 1: Discovery and Governance

• Build the inventory first: every interface, report, connected application, data source, and workflow that touches Cerner, each mapped to the department that depends on it. 
• Interview clinical, revenue cycle, IT, compliance, and research leads separately, because each group has dependencies the others do not know about. 
• Set up a steering group with one named owner for data, one for integrations, and one for clinical adoption. Done when the inventory is signed off by department heads and the three owners are named.

Stage 2: Data Assessment

• Profile the Millennium data for volume, quality, and dependencies before deciding what moves. Count rows per table, identify custom fields and local code sets, and flag tables that reference each other so they are converted together. 
• Apply the three-way classification from the data migration steps above and get legal sign-off on retention. Done when every dataset has a disposition (convert, archive, or destroy) and a quality score.

Stage 3: Build and Test

• Build the extraction pipeline, the field mappings to Chronicles, the validation rules, and the Bridges interfaces in parallel. 
• Run a pilot conversion on a sample that includes the hardest cases: multi-encounter patients, custom fields, scanned documents, and records from acquired facilities with different builds. Test interfaces against the receiving systems, not against a simulator. Done when the pilot reconciles at source, staging, and target and every go-live-critical interface has passed end-to-end testing.

Stage 4: Phased Load

• Load active patient data first, then historical data in batches ordered by clinical value. Keep Cerner running read-only through the load so clinicians can cross-check, and track reconciliation counts per batch rather than per project. 
• Clinical staff run acceptance testing on converted charts during this stage. Done when active data is live in Epic, batch reconciliation is at 100%, and acceptance testing has no open severity-one findings.

Stage 5: Go-Live and Decommission

• Train on Epic workflows, not on the migration; build the super-user network by department; and staff a command center for the first weeks. Monitor interface queues, report usage, and help desk tickets daily.
• Archive the remaining Cerner history where clinicians can open it from Epic, then decommission. Done when the archive is accessible, the interface error rate is at baseline, and the Cerner environment is shut down with retention obligations met.

Epic vs Cerner Data Differences

The two systems differ in how data is stored, queried, exported, and exposed through APIs, and each difference changes how a Cerner to Epic data migration is planned.

Area	Cerner (Oracle Health Millennium)	Epic
Database	Relational Oracle database; data spread across many Millennium tables plus flat files	Chronicles hierarchical database; reporting copies in Clarity (SQL) and Caboodle (warehouse)
Query and reporting	CCL and Discern Explorer	Clarity SQL, Caboodle, Reporting Workbench, SlicerDicer
HL7 v2 interfaces	Cerner interface engine with site-specific message configuration	Epic Bridges; interfaces are rebuilt, not imported
FHIR APIs	Ignite FHIR R4; DSTU2 retired December 2025	Epic FHIR R4 APIs; apps registered through Epic’s developer program and Showroom
Bulk export	Database extracts through CCL or SQL against backups	Bulk FHIR export required of certified EHRs (ONC § 170.215(d)(1)); large historical loads still use Clarity
Document standards	C-CDA, HL7 v2 MDM	C-CDA, HL7 v2 MDM, FHIR DocumentReference
HIPAA exposure added by migration	Extracted PHI held in staging; business associate agreements for every migration vendor; audit logging on each extract	Same obligations on the load side; Epic access roles and audit trails must be live before the first validation load

 Both vendors certify to the same ONC criteria, so the FHIR R4 (4.0.1) and US Core baseline is shared. The differences sit in the proprietary layer underneath, and that is where the engineering hours go. 

What Healthcare Platforms Integrate with Epic and Cerner?

• Medical imaging: PACS and VNA systems receive orders and return results through HL7 ORM and ORU feeds and DICOM modality worklists. Those feeds move to Epic Radiant and Bridges. Folio3’s own PACScribe cloud PACS connects to Epic on exactly this pattern.
• Clinical documentation: Dictation, ambient documentation, and note-generation tools that post to Cerner through MDM messages or FHIR DocumentReference need new Epic endpoints and new launch contexts in Hyperspace, Hyperdrive, or Haiku.
• Risk management and monitoring: Sepsis alerting, deterioration scoring, infection surveillance, and incident-reporting tools consume ADT and results feeds in near real time. Each feed is a Bridges interface to rebuild and test before go-live, not after.
• Population health and analytics: Pipelines built on Millennium tables do not repoint to Clarity on their own. Registries, quality dashboards, and payer reporting need re-engineering against Epic’s schema, or they show empty panels on go-live morning.
• Revenue cycle: Charge feeds, claim scrubbers, and clearinghouse connections move from Cerner’s financial modules to Epic Resolute, and every one needs end-to-end claim testing.
• Devices and third-party apps: Device gateways and SMART on FHIR apps need re-registration and testing against Epic’s FHIR endpoints, with the DSTU2 retirement handled at the same time.

What Does a Cerner to Epic Migration Cost?

Health system	Scale	Reported cost	Reported timeline
Great River Health (Iowa)	3 hospitals	$35 million	18 months
NCH Healthcare System (Florida)	1 million+ patient records	$65 million	January 2021 to June 2022
UAB Health System (Alabama)	Academic health system; EHR, revenue cycle, research	$380 million	Under 2.5 years
AdventHealth (Florida)	52 hospitals, 1,200+ care sites	$660 million	2020 to 2025

 These cover licensing, implementation partner fees, infrastructure, training, and data conversion. 

The integration and report rebuild work from the previous section is usually inside the total but rarely itemized, which is why it surfaces as change orders mid-program. AdventHealth’s reported split was $370 million capital and $290 million operating, a reminder that staffing and parallel operation carry a large share of the cost, not the software.

How Long Does a Cerner to Epic Data Migration Take?

Program timelines in the table above run 18 to 36 months, and the data migration inside them runs roughly 9 to 15 months. The phase ranges below are planning ranges consistent with those announced programs; phases overlap.

Phase	Planning range	Duration dependencies
Planning and inventory	2 to 4 months	Completeness of the interface, report, and app inventory
Backup delivery and extraction	2 to 6 months	Oracle Health backup lead time; extraction method
Mapping and build	4 to 8 months	Number of custom fields, modules, and code sets
Validation cycles	3 to 5 months	Clinical reviewer availability
Parallel run and cutover	1 to 3 months	Go-live date commitment
Archive and decommission	3 to 6 months after go-live	Retention decisions made in planning

12 Cerner to Epic Migration Hurdles

The hurdles below come up in nearly every Cerner to Epic data migration, and each has a planning fix rather than an engineering one.

• Backup delays and fees: The Millennium backup is vendor-controlled, and access, encryption, and format conversion can each carry a charge. Request on day one and put the fees in the budget.
• Discrete and non-discrete mapping: Structured fields and free-text content need separate pipelines. Treating notes and scanned documents as a mapping afterthought is how clinical history goes missing.
• Dependence on Cerner-generated output: Programs that rely on Cerner to push CCDs or HL7 messages inherit the vendor’s throughput and scheduling. Plan an extraction path you control for the bulk history.
• Oracle licensing for compressed data: Some datasets need Oracle licenses and decoding tools before they can be read. Find these during inventory, not during extraction.
• Undocumented CCL reports: Reports built by analysts and former employees are still running in production. Pull the full list from the environment and assign a business owner to each before deciding what to convert.
• Retention decisions deferred: Without a defined archive scope, every dataset defaults to conversion and the project grows mid-stream. Decide what moves, what is archived, and what is destroyed before mapping starts.
• Fragmented builds across environments: Development, test, and production Millennium environments drift apart over years, and acquired hospitals often run different builds again. Pick production as the single source for extraction and document every build variant before mapping.
• Legacy flat files: Millennium keeps thousands of flat files outside the main tables, and some hold clinical or financial history nothing else contains. Inventory them during discovery and decide which are converted, archived, or left behind, with HIM and finance in the room.
• Slow CCL extraction: CCL is built for queries, not bulk export, and large tables can take days per pass. Reserve CCL for targeted pulls and use direct SQL against the backup for volume.
• Data corruption or loss in transfer: Truncated fields, dropped records, and encoding errors appear at every transformation step. Reconcile counts and checksums after each step, not only at the end, so a fault is found in the step that caused it.
• Unclear retention strategy: Covered above under deferred decisions, but it also affects archive design: an archive built after go-live costs more and arrives later than one scoped in Stage 2.
• Gaps in ownership: Extraction, validation, interface rebuild, and report conversion each need a named owner with authority over the people doing the work. Programs that leave these to the implementation partner find they were never in its scope.

Cerner to Epic Migration Changes in 2026

A Cerner to Epic migration planned this year has to meet four requirements that earlier migrations could defer.

AI and Analytics Readiness

Any analytics or AI initiative after go-live depends on the quality of the converted data: consistent code sets, complete problem lists, and dates that survived conversion intact. Convert to Epic’s standard code sets where a local Cerner code has an equivalent, and design Caboodle as the analytics base from the start rather than retrofitting it.

Interoperability Standards

Certified EHRs now have to support FHIR R4 4.0.1, US Core 6.1.0, and Bulk Data Access under ONC’s certification criteria, and Oracle Health has retired DSTU2. Every API-connected app in the inventory should be checked against those versions during Stage 1, so the R4 rebuild runs alongside the migration instead of after it.

Hosting Decisions

Epic customers run on-premises, on Epic-hosted infrastructure, or on public cloud, and many Cerner migrations use the move to change hosting at the same time. Decide this in Stage 1 because it sets the extraction target, the network design for interfaces, and the archive location.

Security During Cerner to Epic Migration

Extracted PHI in staging, vendor access to backups, and temporary interface credentials all widen the attack surface for the length of the program. Apply the same access roles, logging, and encryption to staging that production gets, and close every temporary credential at decommission.

Migrate From Cerner to Epic With Folio3 Digital Health

Folio3 Digital Health builds and supports the integration layers. The HL7 v2 interfaces, FHIR APIs, device connections, and third-party application integrations that a Cerner to Epic migration has to rebuild. We work inside Epic’s review and testing process rather than around it. Our Cerner integration team works with Ignite FHIR R4 and Millennium HL7 feeds, which is the side of a migration that most Epic implementation partners leave to the customer. If your program has an interface inventory that nobody owns, that is where we start.

Closing Note

A Cerner to Epic migration is four programs that share one go-live date: data conversion, interface rebuild, report conversion, and application re-certification. The published budgets, from $35 million to $660 million, cover all four whether or not the plan itemizes them. The programs that finish on time inventory the connected systems before the contract is signed, request the Millennium backup on day one, and assign engineering ownership to the integration layer instead of assuming the implementation partner has it. Everything else in this guide follows from those three decisions.

Frequently Asked Questions 

Which clinical documentation solutions integrate with Epic and Cerner for seamless note handoff?

Speech recognition, dictation, and ambient AI scribes integrate with Epic and Cerner to capture clinical notes and send them directly to patient charts. Transcription and document scanning tools transfer completed notes, forms, and records using HL7 MDM messages or FHIR DocumentReference resources. Specialty documentation tools use FHIR Observation and Condition resources to share structured clinical data alongside narrative notes. Interface engines simplify integration by allowing the same documentation solution to connect with both EHRs without rebuilding the entire workflow. 

What medical imaging platforms integrate seamlessly with Epic and Cerner EHR systems?

PACS, VNA, and radiology reporting platforms connect to both EHRs through the same two paths: HL7 ORM and ORU messages for orders and results, and DICOM modality worklist for study scheduling. Platforms documenting both include PACScribe, Sectra, Philips, GE HealthCare, Merative Merge, Fujifilm Synapse, Agfa Enterprise Imaging, Hyland, and Intelerad. In a Cerner to Epic migration, those feeds move from Cerner’s interface engine to Epic Bridges and Radiant, and the modality worklist is repointed to Epic. 

What is the difference between Cerner conversion and Cerner migration?

Migration is the full move of data and connected systems from Cerner to Epic. Conversion is the step inside it where extracted Cerner data is transformed into Epic’s format. A systems conversion also includes rebuilding interfaces and reports.

How do Epic systems vs. Cerner differ in bulk data-export tools, data-format standards, and HIPAA-related safeguards?

Epic and Cerner both support FHIR R4 APIs, US Core standards, and bulk patient data export. The main difference is how they store and export data. Cerner uses CCL queries or Oracle Millennium databases, while Epic uses Clarity and Caboodle. Both support HL7 and C-CDA formats for sharing healthcare information. For HIPAA security, both provide encryption, access controls, and activity tracking. However, when moving data between systems, healthcare organizations must protect patient information, control vendor access, and follow HIPAA requirements throughout the migration. 

Which systems need to be re-integrated after moving from Cerner to Epic?

Anything connected through HL7 or FHIR: imaging and PACS, clinical documentation and dictation, risk and monitoring tools, population health pipelines, revenue cycle connections, device gateways, and SMART on FHIR apps. Each needs a new Epic interface or registration.

Which healthcare risk management software integrates with Epic and Cerner EHRs for real-time monitoring?

Patient monitoring tools connect with Epic and Cerner to track patient health and alert doctors about possible risks. Epic uses Deterioration Index, while Cerner uses St. John Sepsis. Other tools like Sentri7, Philips Capsule, Bamboo Health, VigiLanz, and RLDatix also work with both systems. When switching from Cerner to Epic, these tools must be connected and tested again to make sure no patient updates or alerts are missed. 

About the Author