For practices, health systems and healthtech teams changing platforms
We migrate clinical, financial and document data out of legacy EHRs, practice-management systems and FHIR platforms. Extraction, mapping to the target model, patient matching, reconciliation, mock migrations, a read-only archive and a go-live parallel run, with every exclusion documented and signed off.
Plan your EHR data migrationHealth IT leaders, practice groups and product teams replacing, consolidating or modernizing clinical systems. Updated September 26, 2026.
Database, vendor export, ONC (b)(10) EHI export, Bulk FHIR or C-CDA
Target model, terminology and patient identity rules
Mock migrations with counts, totals and chart review
Parallel run, delta load, go-live and read-only archive
Illustrative workflow · scope tailored to your environment
The short answer
We extract data from the legacy system through the best available path (database access, vendor export tools, the ONC (b)(10) EHI export that ONC-certified EHRs support, Bulk FHIR or C-CDA documents), map it to the target EHR or FHIR platform, match patients, and load it through repeated mock migrations until counts, financial totals and sampled charts reconcile. Data that does not move stays available in a read-only archive, and go-live runs with a delta load and a parallel-run period.
Read our EHR migration and data portability guideStart with the real problem
Row counts can match while allergies land in the wrong section, medications lose their dose units or two patients are merged. We define what moves as discrete data, what moves as documents and what stays in an archive, then prove the result with reconciliation and clinical chart review before the go-live decision.
What we build
The workstreams in a healthcare data migration, each with the output your team signs off.
Database extracts, vendor export utilities, ONC (b)(10) EHI export files, Bulk FHIR $export and C-CDA or CCD documents. Screen and report extraction is kept as the last resort.
Sizing a legacy EHR data migrationSource-to-target specifications for demographics, problems, medications, allergies, results, immunizations, notes and financials, with ICD-9 history, LOINC, RxNorm and SNOMED CT handling.
Terminology mapping in productionDeterministic and probabilistic matching across sources, duplicate detection and a review queue for uncertain matches before anything is merged.
Patient matching and MPILoads into FHIR stores and servers with US Core validation and Provenance, including moves off Azure API for FHIR before its 30 September 2026 retirement.
FHIR data platform developmentA read-only archive for data that does not migrate, with search, chart view, release-of-information export, retention rules and legal hold.
Healthcare data engineering servicesFreeze windows, final delta load, go/no-go criteria, a parallel-run period where both systems are checked, and hypercare after go-live.
HL7 v2 to FHIR migration guideYour starting point
A practice or health system is moving to a new EHR and must decide what history moves as discrete data, what moves as documents and what stays in an archive.
Several EHRs or practice-management systems hold overlapping patients with different identifiers and local codes.
A product must move FHIR data between stores, for example from Azure API for FHIR to the Azure Health Data Services FHIR service, or from a custom database into FHIR.
The Engineering Engagement
Workstreams are selected around your priorities. Each comes with an output your team can inspect, test and own.
Data domains, date ranges, record counts, attachments, images and extraction paths for every source system.
Discrete, document or archive treatment for each domain, with the reason recorded and approved.
Field-level mapping, code crosswalks, unit handling and provider and location mapping.
Patient, provider and encounter matching with review of uncertain matches.
Two or three full rehearsals comparing counts, financial totals and sampled charts between source and target.
Final delta load, go/no-go, parallel run, archive setup and post-go-live issue handling.
Compare your options
Most EHR migrations combine these. The choice is made per data domain and date range.
| Approach | What moves | Best when | Plan for |
|---|---|---|---|
| Full discrete migration | All structured history into the new EHR | Few sources, good data quality, clinicians need trending across years | Highest mapping and reconciliation effort; legacy code sets |
| Selective migration plus archive | Active problems, medications, allergies, immunizations, recent results and visits; the rest archived | Most practice and hospital EHR replacements | Clear cut-off rules and an archive clinicians can reach from the new EHR |
| Document-level migration | C-CDA, CCD or PDF chart summaries attached to the patient | Older history that must be visible but not computable | Document indexing and search; no clinical decision support on the content |
| Archive only | Nothing into the new EHR; legacy data in a read-only archive | Short retention windows or a low-value source | Retention periods, release-of-information workflow and archive licensing |
Expertise is in the decisions
Agree domains and date ranges with clinical, revenue-cycle and compliance owners. Retention requirements set the archive, not the migration scope.
Discrete data drives decision support and trending; documents preserve context at lower cost. Choose per domain.
Decide whether open A/R is worked down in the old system or migrated as balances, before mapping starts.
Define the matching rules and who reviews uncertain matches. Never merge on a name and date of birth alone.
Agree the counts, totals and number of sampled charts that authorize go-live before the first mock migration.
Decide how long the old system stays read-only, and when the archive takes over.
Export access, vendor export fees and database credentials sit with you and the legacy vendor. We prepare the requests and test the extracts.
The new EHR vendor configures the target build. We load into it through its supported import tools or APIs.
Clinical owners approve mappings with clinical meaning and review sampled charts before go-live.
Your compliance team sets retention periods under state law and payer contracts; we implement them in the archive.
Timeline
Typical durations for a single-source EHR migration. Multi-source consolidations add a mapping and matching cycle per source.
3 to 4 weeks. Source inventory, extraction tests, scope decisions and acceptance criteria.
4 to 8 weeks. Mapping specifications, crosswalks, match rules and extraction and load tooling.
4 to 8 weeks for two or three rehearsals, each with reconciliation and chart review.
1 to 2 weeks of cutover and parallel run, then 30 to 90 days of hypercare.
Delivered work
Client names are withheld; each is a real engagement. Our open-source EHR work is public on GitHub.
A headless EHR with a FHIR R4 API, Bulk Data export and SMART App Launch that passed 47 of 47 ONC (g)(10) SMART App Launch standalone patient tests in Inferno on 11 June 2026.
A provider platform whose every patient, appointment, care plan and invoice is a standard FHIR resource, so its data can move to any FHIR-capable system without a bespoke export.
Clinical data validated against templates before it lands, with a master patient index, researcher roles, audit and cohort export to FHIR or openEHR.
An existing 837 and 835 claims pipeline diagnosed and hardened inside a production EHR with reviewed fixes and automated tests, keeping claim data consistent while the system stayed live.
From discussion to delivery
Inventory every source and agree what moves, how and how far back.
Write signed mappings and repeatable extract, transform and load tooling.
Run mock migrations until counts, totals and sampled charts pass the agreed checks.
Execute the delta load, run in parallel, go live and support the first weeks.
We agree the scope, dependencies, acceptance criteria and commercial model before implementation. Your existing team can stay involved throughout.
Find the right starting point ↗EHR data migration is moving patient records, clinical history, documents and financial data from a legacy EHR or practice-management system into a new one, or into an archive. It covers extraction, mapping to the target model, patient matching, loading, reconciliation and the go-live cutover.
A single-source migration typically takes 12 to 22 weeks: 3 to 4 weeks of discovery, 4 to 8 weeks of mapping and tooling, 4 to 8 weeks of mock migrations and 1 to 2 weeks of cutover, followed by hypercare. Consolidating several sources adds a cycle per source.
The number of source systems, years of history, the share of data migrated as discrete data, attachments and images, source data quality and duplicates, legacy vendor cooperation and export fees, the number of mock migrations and archive requirements. We estimate after discovery.
Most organizations migrate active problems, medications, allergies, immunizations, recent results and recent visits as discrete data, attach older summaries as documents and keep the full history in a read-only archive. The split is agreed per domain with clinical and compliance owners.
Since 31 December 2023, ONC-certified EHRs that store electronic health information have had to support the (b)(10) EHI export for a single patient and for a patient population. We also use database access, Bulk FHIR, C-CDA documents and vendor reporting tools, and keep screen extraction as the last resort.
Yes. We map records to FHIR R4 resources, validate them against US Core or your profiles, keep source identifiers and Provenance, and reconcile the load. That includes moving from Azure API for FHIR to the Azure Health Data Services FHIR service before the 30 September 2026 retirement.
Each mock migration is reconciled by record counts per domain, financial control totals, referential checks between patients, encounters and orders, and a clinical review of sampled charts in the target system. Go-live requires the agreed checks to pass.
During a parallel run, the legacy system stays available read-only while the new system goes live, so staff can compare charts and balances and the team can resolve differences quickly. It usually lasts one to several weeks before the legacy system moves to archive.
We match patients with deterministic rules on strong identifiers, add probabilistic scoring for weaker matches, and send uncertain matches to a human review queue. Merges are logged so they can be traced after go-live.
We rehearse the cutover in mock migrations, load history before go-live, move only a final delta during the freeze window, and keep the legacy system available read-only. Any residual risk is listed in the go/no-go record for your sign-off.
Medical record retention is set by state law, payer contracts and your policies, and differs for adults and minors. We implement the periods your compliance team sets in the archive, including legal holds.
Your authorized stakeholders decide retention, access and decommissioning. We provide the inventory, migration evidence and archive that support that decision.
A useful first conversation
Tell us what exists today, who uses it and where the workflow breaks. We’ll discuss the scope, access dependencies and the next practical step.
A product overview and a de-identified workflow are enough to start. No patient records or credentials are needed.
These are independent reference sources, not endorsements. Applicability, platform access and current requirements are confirmed for your project.
