Patient Data Migration Services: Extracting a Full Registry From a Legacy EHR With No Export Button

Patient data migration services exist because of one specific failure: the software holding your records was never built to let them leave. A private healthcare practice came to us fully trapped inside a legacy clinical management system. Scheduling, billing and patient records had all lived there for years, the decision to move had already been made, and the new platform contract was already signed. Then they discovered there was no CSV download, no API handoff, no data portability menu. Just a web interface and thousands of patient records behind it.

This is the point where most practice migrations quietly die. Ours did not.

Why Patient Data Migration Stalls: Legacy Systems Have No Export Button

The answer first: it is almost never a technical limitation. It is a commercial decision, and in the United States it is now frequently an illegal one.

Platforms built in the 2000s and early 2010s were architected around retention, not interoperability. Data portability was not a feature anyone was asked to ship, and once a practice had five years of records inside, the absence of an export path became the single strongest reason they would not leave. That is not an accident of engineering. It is the business model.

What makes this so frustrating for practice managers is that the data is visibly right there. Every patient record, every contact detail, every specialist assignment renders on screen. The gap is not between "we have the data" and "we do not." It is between visible and portable, and that gap is where migrations go to die.

This is the deeper version of what we call the legacy access problem. In our experience it is the single most overlooked blocker in any project that touches an existing business system, and it is almost never discovered during vendor selection. It is discovered in week seven, when the new platform is paid for and the old one will not let go. We cover the wider pattern in our guide to AI for medical practices and the operational side in agentic AI for medical practice admin.

The Rule Almost Every Migration Article Gets Wrong

Here is the part that competing healthcare data migration providers tend not to print, because it complicates the sales pitch in both directions.

In the United States, a certified EHR legally must have an export. Under the 21st Century Cures Act, ONC certification criterion §170.315(b)(10) requires certified health IT that electronically stores electronic health information to support EHI export in two contexts: single-patient export, and full-population export specifically for the case where a provider is switching systems. Compliance was required by the end of 2023. More pointedly, the regulations state that a fee charged to perform that export for the purpose of switching systems does not qualify for the Fees Exception under the information blocking rules. Charging you a five-figure "professional services" fee to leave is, in many cases, the violation.

The teeth are real and newly sharpened. The HHS Office of Inspector General finalised civil monetary penalties of up to $1 million per violation against health IT developers, health information networks and exchanges, effective 1 September 2023. Through 2026, HHS has confirmed it is issuing notices of potential non-conformity, has placed organisations on corrective action plans, and has more than 2,000 complaints under review, with ASTP/ONC sharing complaint data directly with OIG.

So why was our client still stuck? Because the rule reaches certified health IT, and an enormous share of private practice, specialist clinic and allied health software is not ONC-certified at all. Physiotherapy, dermatology, cosmetic medicine, psychology and dental platforms serve narrower markets, face less regulatory pressure, and frequently sit entirely outside the certification programme. If your vendor is not certified, §170.315(b)(10) does not apply to them, and no amount of citing it will produce an export file.

And the UK position is weaker still, not stronger. Practice managers are routinely told to invoke UK GDPR Article 20, the right to data portability. In this scenario that advice is usually wrong. Article 20 applies only where processing rests on consent or contract, and only to data the individual provided. Clinical processing in the UK typically runs on Article 6(1)(c) or 6(1)(e) with Article 9(2)(h), which are explicitly outside Article 20's scope. Article 20 is also an individual's right, not a practice's. A clinic cannot use it to bulk-extract its own registry.

The practice's actual leverage is more mundane and more durable: it is the data controller, and the vendor is its processor. The records are the practice's own, held under a contract the practice signed. That is the ground you stand on. Not Article 20. The ICO's guidance is useful in one respect though: where no format is standard in an industry, it names open formats such as CSV, JSON and XML, and states plainly that a PDF is not machine readable. Anyone offering you a PDF dump as a "migration" is not offering a migration.

What We Actually Did

Step 1: Discovery and Destination Mapping

Before touching a record we mapped what existed, where it lived in the interface, and what the destination system required. For this practice the critical fields were full name, complete mailing address, date of birth, mobile number, email address and assigned specialist.

There is a fast diagnostic that any practice manager can run before hiring anyone. Look at every core platform you rely on and ask one question of each: does it publish an API, an MCP server, or a documented integration path? If yes, integration is predictable, and in our experience the success rate is well above 90 percent. If no, the work is still possible, but it changes shape: the system has to be operated the way a human operates it, through the screen. That is browser automation, and it is inherently more brittle. It breaks when the vendor moves a button. It is the difference between a door and a window you have to climb through every time.

This client's system had no door. So we built for the window, deliberately and with the maintenance cost priced in honestly.

Step 2: Controlled, Compliant Extraction

We built a tailored extraction process around four non-negotiable principles.

Non-invasive by design. Everything ran inside the practice's existing authenticated session. No credentials left the practice, no new access was provisioned, no system control was bypassed. Every action was equivalent to a staff member working through records at a screen, just faster, more consistent, and capturing structured data at each step. This distinction matters legally as well as technically: the practice was accessing its own data through access it already held.

Rate-controlled and considerate. The process was deliberately paced with realistic inter-action delays, avoiding unusual load on the source system or anything that would look anomalous to automated monitoring.

Auditable and resumable. Progress was checkpointed throughout, so the run could be paused for review and restarted without losing work or creating duplicates. Every record extracted was logged, giving the practice a clean trail of what moved, when, and in what form.

Accurate at the field level. Parsing an interface is not the same as reading an export file. We ran multi-pass validation at every stage, checking date capture, normalising phone formats, verifying address completeness, and confirming specialist associations. Ambiguous records were flagged for human review rather than guessed at.

The entire extraction ran outside business hours. There was zero disruption to daily operations.

Step 3: Data Review and Cleaning

Raw extraction output is never import-ready. We reviewed the full dataset for record completeness, format consistency, duplicate detection across name variants, and edge cases such as non-standard characters and overlong address fields.

What the Data Actually Looked Like

The records below are 100% synthetic, made-up data for illustration only. No real patient information appears anywhere in this case study. To make that unmistakable, every name in the sample tables below is a Marvel Cinematic Universe character name. The addresses, contact details and clinician names are likewise invented, and the practice itself is not identified. The records are constructed to reproduce the exact categories of inconsistency we encountered.

Before: Raw Capture From the Legacy Interface

What is wrong with this, field by field:

• Name casing is not uniform. All-caps, all-lowercase, prefixes (Mr.), initials only. Nothing is consistent.
• Three different date formats in eight records. 14/03/1978, 02-09-1965, 1955-04-22. A direct import silently misparses roughly half of these, and a misparsed date of birth in a clinical system is a patient safety issue, not a formatting nit.
• Every phone number is formatted differently. Country codes present or absent, spaces, dashes, nothing. 447812 000 199 is not a valid UK domestic format and needs interpretation before normalisation.
• Specialist names do not resolve to an identifier. Dr. Stephen Strange, dr strange and Dr. Strange are one clinician. A destination expecting a lookup ID rejects or orphans two of those three.
• Record 1 has a space inside the email address, an artefact of how the source interface rendered the field. This causes a silent import failure, which is the worst kind.
• Record 7 has no specialist. Record 3 has no email. These are known nulls, not errors, and must be handled as such.
• Addresses carry inconsistent line breaks and trailing county lines that match no standard address schema.

None of this is unusual. This is what a legacy clinical interface yields when there is no native export. It is all there, and none of it is clean.

The Cleaning Pass

After: Migration-Ready

Every date is unambiguous. Every phone number is digit-clean and consistently formatted. Every specialist reference resolves to a lookup ID (SP-001 and SP-002), so the relationship between patient and clinician survives the move. Address fields match the destination schema exactly. Known nulls are cleanly empty.

Relational Integrity: The Risk Nobody Budgets For

The most underappreciated failure mode in healthcare data migration is relational breakage, where records survive but the connections between them do not.

Patient records do not exist alone. They connect to clinicians, appointment history, billing records and referral pathways. If a specialist reference arrives as free text in a system expecting a numeric ID, that patient lands with no assigned clinician. Clinically that is a gap. Administratively it is a problem the practice untangles by hand, one record at a time, which is precisely the manual work the migration was supposed to eliminate.

Our cleaning pass targets relational fields first. Every name-variant-to-ID mapping is built and verified before the import runs, so references resolve on arrival rather than being repaired afterwards.

Where a Privately Hosted Model Earns Its Place

Rules-based normalisation handles the majority of the mess in a legacy export: casing, date formats, phone formats. But the harder cases are the proper nouns, the free-text clinician names, the address components that a fixed rule set cannot fully anticipate, dr strange versus Dr. Strange versus a clinician recorded only by surname. This is where a privately hosted, GDPR-compliant model earns its place in the pipeline rather than a generic cloud AI API.

Running a self-hosted model inside infrastructure that never sends patient data outside the practice's own compliance boundary means the entity resolution step, matching name variants to a canonical clinician, catching misspellings, flagging a record that looks like a duplicate under a different spelling, can be handled with genuine language understanding rather than brittle string matching, without the data ever touching a third-party API. That combination, private hosting plus a model doing the noun and name normalisation work, is what lets this kind of cleaning scale past a handful of clinicians without every edge case becoming a manual ticket.

The Result

• Zero manual re-entry. Not one record was typed by hand by any member of staff.
• Full field-level fidelity, including specialist assignments, structured addresses, and normalised dates and phone numbers.
• No operational disruption. Extraction ran outside business hours; the practice opened the next morning on the new system.
• A complete audit trail of what was extracted, when, and in what format, supporting future governance and compliance requirements.
• First-attempt import success, with record counts matching exactly on both sides and no silent rejections.

What had been presented as an indefinite blocker, a migration that "could not be done" without vendor involvement, was completed in a matter of days.

The Competitor Pulse Check

Where Open Source Genuinely Solves This

We would rather tell you when you do not need us. If your source system exposes any structured interface at all, several mature open-source projects handle the transformation layer well and are worth evaluating before commissioning bespoke work:

• Mirth Connect for HL7 and general clinical message routing and transformation. If your legacy system can emit HL7 at all, this is usually the cheapest correct answer.
• HAPI FHIR for building a standards-compliant FHIR layer between systems. We cover it in depth in our HAPI FHIR interoperability guide.
• Medplum as an open-source, FHIR-native backend when the destination is a system you are building yourself. See our Medplum walkthrough.
• OpenEMR and OpenMRS as destination platforms in their own right, both with documented import paths. Our reviews: OpenEMR and OpenMRS.
• Synthea for generating synthetic patient data to test an import end to end before a single real record moves. This step is skipped far too often. See our Synthea guide.

None of these help when the source system has no machine interface whatsoever, which is the case this study describes. That is the narrow, genuinely hard problem, and it is the one worth paying for.

Choosing Patient Data Migration Services: What To Ask First

Is your data actually inaccessible, or just inconvenient to access? In nearly every case we have seen, the data exists and is fully readable within the system. What is missing is the pathway out. That is a different problem, and it is solvable.

Check whether your vendor is ONC-certified first. If you are in the United States and your system is certified, you may not need a migration project at all. You may need to cite §170.315(b)(10), point out that a switching-purpose export fee does not fall under the Fees Exception, and file an information blocking complaint. That route is free and increasingly effective. If your vendor is uncertified, or you are in the UK, that lever does not exist and you are back to engineering.

What does the destination system actually need? Import requirements vary enormously. Date format expectations, character limits on address fields, clinician lookup tables that must be pre-populated before patient records can reference them. Getting extraction right matters. Landing it correctly matters just as much, and most providers stop at the file handover.

What is the realistic risk of manual re-entry? This is the question practices under-weight most. Manual transfer at scale is never as accurate as it feels like it should be. Humans make errors at higher rates than they expect under repetitive conditions, and in healthcare, a transposed digit in a date of birth or a missed specialist assignment carries real downstream consequences. A controlled extraction from a system without native export carries materially lower data-quality risk than typing the records in.

What EHR Data Migration Services Cost: Indicative Pricing

Migration scope varies with record volume, field complexity and how hostile the source interface is. Our typical bands:

• Registry extraction and migration (2 to 4 weeks): £4,000 to £12,000 / $5,000 to $15,000
• Multi-entity migration with clinical history and billing (6 to 10 weeks): £12,000 to £32,000 / $15,000 to $40,000
• Multi-site consolidation, deduplication and archival compliance (10+ weeks): £32,000+ / $40,000+

For context, published industry benchmarks put small-practice EHR migrations at roughly $5,000 to $20,000 over 3 to 10 weeks, mid-market projects commonly at $20,000 to $50,000, and enterprise Epic migrations at $100,000 to $500,000 or more. If a quote is dramatically below the band for your record volume, ask specifically who performs the data cleaning, because that is the line item usually being omitted.

Frequently Asked Questions

Can you migrate patient data from a system with no export function?

Yes. Where a legacy clinical system offers no CSV download, API or export menu, patient data migration is performed at the interface level, working within the practice's own existing authenticated access. The records are captured, validated field by field, cleaned, and mapped to the destination system's import specification. No credentials leave the practice and no system controls are bypassed.

Is it legal for a healthcare software vendor to refuse to export my patient data?

In the United States, if the product is ONC-certified health IT that electronically stores electronic health information, it is required to support EHI export under certification criterion §170.315(b)(10), and charging a fee to export for the purpose of switching systems does not qualify for the Fees Exception under the information blocking rules. Health IT developers face civil monetary penalties of up to $1 million per violation. Many private practice and specialist clinic platforms are not certified, however, and fall outside those requirements entirely.

Does UK GDPR Article 20 let a practice extract its patient registry from a vendor?

Generally no, and this is widely misunderstood. Article 20 applies only where processing is based on consent or contract and only to data the individual themselves provided, whereas clinical processing usually relies on other lawful bases. It is also an individual's right rather than an organisation's. A UK practice's real leverage is its status as data controller under its contract with the vendor, not Article 20.

How much do patient data migration services cost?

Published benchmarks put small-practice EHR data migration at roughly $5,000 to $20,000 over 3 to 10 weeks, with mid-market projects commonly landing between $20,000 and $50,000 and large enterprise migrations running well into six figures. Cost is driven primarily by record volume, the number of distinct data types, and how much cleaning the source data requires rather than by the extraction itself.

How long does a legacy EHR data migration take?

A single-registry extraction and migration for a private practice typically runs two to four weeks including discovery, extraction, cleaning and import support. Projects involving clinical history, billing records or multiple source systems run longer. Extraction is rarely the bottleneck; data mapping and validation usually consume the largest share of the timeline.

Will migrating disrupt the practice's daily operations?

It should not. Extraction is scheduled outside business hours and paced to avoid unusual load on the source system, and the process is checkpointed so it can be paused and resumed without losing progress or duplicating records. In this engagement the practice closed on the legacy system and opened the following morning on the new platform.

What happens to specialist and clinician assignments during migration?

They are the most commonly broken field in a healthcare migration. Source systems usually store clinician references as inconsistent free text, while destination systems expect a lookup ID. Every name variant must be resolved to a canonical identifier before import, otherwise patient records arrive with no assigned specialist and the practice has to repair them manually.

Getting Started

If you are planning a migration from a system that lacks export functionality, or you are mid-project and have hit a wall, we will assess your situation and tell you plainly what is possible, what it involves, how long it takes and what it costs. If open source or an information blocking complaint solves it more cheaply than we can, we will say so.

Practices should not stay trapped in software they have outgrown because a vendor decided data portability was optional. The data is yours. Getting it out should be possible.

Book a migration assessment or read more about our AI consulting and integration services.

Patient data migration services for private healthcare practices, specialist clinics and healthcare organisations, with particular focus on legacy clinical management and practice administration systems that offer no native export path. All patient records shown in this case study are fictional dummy data.