Every EMR migration I've been part of has lost something. The question is never whether data will be lost or distorted, but which data, how much, and whether anyone notices before it affects a patient encounter. For compounding practices, the stakes are higher than for a general primary-care clinic, because so much of what you do lives in fields the source system was never designed to hold cleanly: formula components, strengths with non-standard units, lot numbers, beyond-use dates, patient-specific tolerance notes, prescriber preferences by base.

If you're planning a move off a legacy EMR, or off a stitched-together setup of Jane or Athena plus a pharmacy system plus a dozen spreadsheets, this is the piece I wish someone had handed me the first time I did it.

Where compounding data actually lives, and why that matters

In a standard EMR, a prescription is a structured object: drug, strength, form, sig, quantity, refills. The whole system is built around that shape. A compounded prescription rarely fits. You might have a cream with four actives at different concentrations, a preservative, a base, and a sig that references application sites by diagram. The source EMR probably stored most of that as free text in a notes field, or in a custom field someone built in year three, or in a PDF attached to the chart.

When you map that into a new system, the ingestion script sees a prescription row and writes a prescription row. The notes field may or may not come across. The custom field almost certainly won't, unless you tell the migration team it exists. The PDF comes across as a document but loses its link to the specific encounter. You now have a chart that looks complete on first glance and is quietly missing the clinical reasoning behind the formula.

This is the core issue with compounding migrations. The data model mismatch is bigger than it looks, and the things most likely to be dropped are the things your prescribers rely on to refill accurately.

The categories that get lost most often

In practice, these are the fields I see go missing or get mangled, roughly in order of frequency:

  • Formula composition detail. Individual actives, concentrations, bases, and the rationale for each. Legacy systems often store the finished product name but not the recipe behind it.
  • Patient-specific adjustments. "Reduce progesterone to 75mg after Jan visit, patient reported breast tenderness." These notes live in encounter text and don't migrate as structured allergy or intolerance data.
  • Lot and BUD history. Which lot the patient actually received, when, and the beyond-use date. Critical for recall response and for any adverse event investigation.
  • Prescriber preferences and standing protocols. The unwritten rules of your practice. Dr. A always starts low-dose naltrexone at 0.5mg. Dr. B prefers MCT oil base for sublingual troches. These usually live in people's heads or in a shared doc.
  • Refill authorization chains. Who approved what, when, and under what conditions. Audit trails rarely survive migration intact.
  • Lab result linkages. Hormone panels tied to dosing decisions. The lab PDFs come over. The clinical thread connecting the April testosterone level to the May dose change usually does not.
  • Communication history. Texts, portal messages, call logs. Often stored in a separate CRM or in the phone system, and almost never pulled into migration scope.
  • Pricing and insurance context. Cash-pay histories, sliding scales, subscription membership status. Lives in the billing system and gets reconciled badly.

Any one of these, missed, is survivable. Several of them missed at once is how practices end up calling patients to re-collect information six months after go-live.

How to scope the migration before anyone touches a database

The best migrations I've seen start with a field-level inventory of the source system, done by someone who actually uses it daily. Not the vendor's export tool output. A human walking through every tab of a representative chart and writing down what's there, what it means clinically, and whether it exists as a structured field or free text.

Pick ten charts that represent your range: a straightforward BHRT patient, a complex multi-formula case, a pediatric patient, a patient with a documented adverse reaction, a long-tenured patient with years of history, a recent new intake, a telehealth-only patient, a patient who switched prescribers mid-care, a patient on a subscription membership, and a patient who's had a refill denied or adjusted. Walk every chart end to end. Document every field that holds clinical meaning.

That document becomes your mapping specification. Give it to the migration team and require them to tell you, field by field, where each piece of data will land in the new system and what happens if there's no destination for it. "No destination" is a legitimate answer, but it needs to be a decision, not an accident.

Validation that actually catches problems

Record counts are not validation. If 12,000 patients went in and 12,000 came out, you've confirmed almost nothing about data integrity. Real validation is clinical: can your prescriber open a chart in the new system and refill the patient's current formula without opening the old system to check anything?

Run that test on the same ten charts you used for scoping. Then run it on another thirty picked at random. If prescribers can refill cleanly on forty consecutive charts without reference to the legacy system, you have a migration that works. If they can't, you know exactly which fields are failing and can fix the mapping before cutover.

Build in a parallel-run period of at least two weeks. Both systems live, with the new one as primary and the old one available as a reference. This is annoying and expensive. It also catches the problems that only show up when real work hits the system.

What to do about the things that genuinely can't migrate

Some data won't come across cleanly no matter how carefully you plan. Scanned paper charts from before you went digital. Communication threads from a messaging platform that doesn't export. Pricing arrangements negotiated verbally and never written down.

For these, the honest answer is to decide what gets manually re-entered, what gets archived as read-only reference, and what gets accepted as lost. Write that decision down. Tell the clinical team what they'll be able to find in the new system and what they'll need to ask the patient about on the next visit. The worst outcome is a staff member assuming data is there, searching for it, not finding it, and improvising.

A note on compounding-specific infrastructure

Most general-purpose EMRs will accept your compounding data in some form, but acceptance isn't the same as support. If the new system doesn't natively model formulas, lots, and BUDs, you'll end up back in free-text workarounds within a year. Before you commit, have a prescriber and a pharmacy tech sit with the new system and build three real formulas end to end, including documentation, dispensing, and refill. If it feels like fighting the software, it will keep feeling that way after go-live.

This is the gap we built Qintara to close for compounding and concierge practices specifically. If you're mapping out a migration and want to see what native compounding support looks like in an EMR, talk to our team and we'll walk through your current data model with you.

Frequently Asked Questions

How long should a compounding EMR migration realistically take?

From signed contract to stable go-live, plan on four to six months for a practice with a few thousand active patients and complex formulas. Smaller practices with cleaner data can move faster. Anyone promising you a two-week cutover on a compounding practice has not done one before.

Should we migrate all historical data or start fresh?

Migrate active patients with full clinical history. For inactive patients (no visit in two or three years), consider archiving the old system as read-only reference rather than paying to migrate charts you may never open. Confirm your retention obligations with your own counsel before deleting anything.

Who should own the mapping document on our side?

Someone clinical, not someone operational. The mapping is a clinical safety document in disguise. A practice manager can coordinate the project, but a prescriber or clinical pharmacist needs to sign off that the fields coming across preserve the information needed to treat patients safely.

What's the single most common cause of a bad compounding migration?

Treating the formula as a product rather than a recipe. If the new system stores "Formula #3471" as a drug name and loses the ingredient breakdown, every future adjustment becomes guesswork. Confirm during the scoping phase that composition data has a structured destination.

How do we handle controlled substance records during migration?

Keep them in a separate workstream with extra validation and a documented chain of custody for the data. DEA recordkeeping requirements don't pause for your software project, and gaps in controlled substance history are the kind of finding that triggers broader scrutiny. Your compliance officer and counsel should sign off on the approach before execution.