Every practice owner I know who has migrated an EMR has the same regret: they didn't ask hard enough questions about data portability before signing. Not the marketing question ("Can I export my data?") but the operator question ("What exactly do I get, in what format, on what timeline, and what happens to the fields your system uses but the schema doesn't cover?"). The answers determine whether your next migration takes six weeks or six months, and whether you actually own your clinical history or just rent access to it.

This piece is a checklist for the conversation you need to have with any vendor before you sign, and a set of tests you should run on your current vendor before you assume you can leave when you want to.

Why portability is a governance issue, not an IT issue

Data portability gets treated like a technical question, so it ends up on an IT person's desk or, worse, buried in a contract addendum nobody reads. In practice, it belongs with whoever owns clinical operations and vendor risk. If your EMR vendor gets acquired, raises prices 40%, or sunsets a module you depend on, your leverage is entirely a function of how cleanly you can leave. A vendor that makes exit easy is a vendor you'll probably stay with. A vendor that makes exit hard is one you'll resent long before you actually try to go.

The compounding and concierge practices we work with tend to accumulate weird, valuable data: custom formulation notes, membership terms, longitudinal lab trends, intake questionnaires that evolved over years. None of that lives in a standard HL7 or FHIR field. When you export, that's the data most likely to arrive as an unlabeled blob or, worse, not arrive at all.

What to demand in writing, before you sign

1. A named export format, not a promise

"We support data export" means nothing. Get the vendor to specify: CSV per table, FHIR bundles, HL7 v2 messages, PDF chart summaries, native database dumps, or some combination. Ask for a sample export from a demo tenant. If they can't produce one within a week, that tells you everything about what your export will look like on day one of your migration.

2. A complete data dictionary

You need documentation of every table, every field, every enumerated value, and every relationship. Without it, a downstream vendor is guessing. I've seen migrations where a field labeled status_2 turned out to be the only place a critical clinical flag was stored, and nobody figured that out until three months post-cutover when refill workflows started breaking.

3. Attachments and unstructured content

Lab PDFs, signed consent forms, scanned insurance cards, faxed referrals, photos, secure message threads, portal uploads. Ask specifically: are these included in the export, in their original format, with metadata that ties them back to the right patient and encounter? A lot of exports return you a folder of files named by UUID with no join table. That's not portability, that's a scavenger hunt.

4. Audit logs and metadata

Who saw what, when, and what did they change? For compounding practices especially, the audit trail is not optional. If your export doesn't include it, you have a compliance problem the moment you leave. Get the retention period and export format in writing.

5. A defined SLA on export delivery

How many days from request to delivery? What happens if the vendor misses that window? I'd push for something concrete: 30 days for a standard export, 60 for a full historical dump with attachments, with financial penalties for delay. Vendors will resist this. That's the point of asking. Their resistance tells you what happens when you actually try to leave.

6. Cost, spelled out

Some vendors charge a flat migration fee. Some charge per record. Some charge per gigabyte for attachments. Some charge "professional services" hours at $300 an hour with no cap. Get a not-to-exceed number in the contract, or a fee schedule that lets you predict the bill within 10%.

7. Post-termination access

After you cancel, how long do you retain read access? Most contracts default to 30 or 60 days, which is not enough time to validate a migration under any realistic scenario. Push for 12 months of read-only access at a reasonable rate. If they refuse, know that going in.

Tests to run before you're stuck

If you're already on an EMR and haven't confirmed you can leave cleanly, do this now, while you're not under pressure:

  • Request a sample export of 50 patient records including all attachments, notes, and messages. See what actually shows up.
  • Pick one complex patient (long history, many documents, custom fields) and ask for their complete record. Time it. Review it with a clinician.
  • Ask your vendor for their data dictionary. If they won't share it, that's the answer.
  • Read your current contract's termination clause. Note the notice period, the export terms, and any fees. Calendar the notice period on your renewal date.

You want to discover the ugly parts of your vendor's export process on a Tuesday afternoon when you're just curious, not on the Monday you're trying to cut over to a new system.

The formats that actually matter

FHIR is the direction the industry is moving, and any vendor building today should offer FHIR-native exports for the resources FHIR covers well: Patient, Encounter, Observation, MedicationRequest, DocumentReference, and so on. For everything else, structured CSV with a documented schema is fine and often better, because it makes weird custom fields explicit rather than trying to jam them into a FHIR extension nobody will parse.

What you don't want: PDFs of chart notes as the only export option. That's not data, that's a picture of data. If your vendor's answer to "how do I get my records out" is "we generate a PDF per patient," you have no portability. You have a paper filing cabinet with extra steps.

Migration is a two-vendor problem

One thing that surprises people the first time they migrate: the receiving vendor matters as much as the sending one. A great export is useless if the new system can't ingest it. When you're evaluating a new EMR, ask them to walk you through a migration they've actually done from your current vendor. Ask what broke. Ask what the client had to clean up manually. Ask how long it took from signed contract to go-live.

At Qintara we spend a lot of time on ingestion tooling because we've watched too many practices lose weeks to preventable schema mismatches. If you want to see how we handle EMR migration for compounding and concierge practices, including how we deal with custom fields and attachment metadata, talk to our team.

Frequently Asked Questions

Does HIPAA require my vendor to give me my data?

HIPAA gives patients rights to their records; the business relationship between you and your EMR vendor is governed primarily by your contract and BAA, plus state law. In practice, most vendors will provide exports, but the format, timeline, and cost are contractual. Confirm the specifics with your own counsel.

What's a reasonable timeline for a full EMR migration?

For a small practice with a clean data set and a cooperative outgoing vendor, 60 to 90 days from contract signature to full cutover is realistic. Add time for messy data, uncooperative vendors, or custom integrations. Practices that try to compress this into 30 days usually pay for it in the first month post-cutover with broken workflows and missing records.

Should I keep a copy of my data even if I'm not planning to migrate?

Yes. Request a full export annually and store it somewhere you control, encrypted and access-logged. If your vendor has an outage, gets acquired, or disputes a bill, you're not negotiating from zero. This is basic operational hygiene and most practices skip it.

What about data we generated in third-party tools connected to the EMR?

Every integration is its own portability question. Your labs, your e-prescribing history, your patient messaging platform, your payment processor: each has its own export terms. Map them all. The EMR is usually the biggest piece, but it's rarely the only one.