Most EMR migrations fail in the discovery phase, not the cutover. By the time you're loading patient records into a new system, the damage from a sloppy audit is already baked in: missing custom fields, broken workflows your old vendor never documented, three years of refill notes trapped in a free-text field nobody knew existed. The work of a good migration starts months earlier, with an honest look at what you actually have.

If you manage a practice and you're staring down a vendor switch, this is the audit I'd run before signing anything. It's the same one I've used to migrate compounding-heavy concierge practices off legacy systems, and it surfaces the landmines while you still have time to plan around them.

Start With a Data Inventory, Not a Feature Comparison

Practice managers tend to start EMR evaluations by comparing feature lists between the old and new vendor. That's backwards. Before you can judge whether a new system fits, you need to know what data you actually have in the current one. Not what the vendor told you it stores. What's really in there.

Pull a sample of 25 to 50 patient charts across your most common visit types. For each one, document every field that contains data, including the ones your staff filled in as workarounds. In practice, the workarounds are where the real clinical information lives. A field labeled "allergies" might hold medication preferences. A "notes" field on the patient demographics screen might be the only place anyone recorded which compounded formulations a patient is on.

Build a spreadsheet with these columns:

  • Field name as it appears in the EMR
  • Where it lives (patient demographics, encounter note, custom form, etc.)
  • What it's actually used for (which may differ from its label)
  • Whether it's structured (dropdown, checkbox) or free text
  • How often it's populated
  • Who owns the data entry (front desk, MA, provider, billing)

This becomes the source of truth when you're mapping fields to the new system. Skip this step and you'll discover during go-live that your refill protocols, your dosing notes, or your custom intake fields have no home in the new EMR.

Map Your Workflows Against the System

Every clinic runs workflows the EMR doesn't formally support. A nurse exports a CSV every Friday and reformats it for the compounding pharmacy. The front desk keeps a separate spreadsheet of preferred-patient pricing because the EMR's billing module can't handle it. Someone has a Google Doc that maps internal abbreviations to ICD-10 codes.

List every workflow that touches the EMR, including the ones that route around it. I'd start with these categories and let your staff add to the list:

  • New patient intake (from inquiry through first appointment)
  • Scheduling and rescheduling, including waitlist management
  • Refill requests and renewals
  • Lab ordering and result handling
  • Compounded prescription routing and tracking
  • Patient messaging and follow-up
  • Billing, superbills, and any membership or subscription logic
  • Reporting for owners, clinicians, or compliance

For each workflow, write down the steps, the time it takes, and the people involved. Mark the steps that happen outside the EMR with a flag. Those flagged steps are your migration risk. If you don't plan for them in the new system, your staff will rebuild the same workarounds within a month, and you'll have paid for software that doesn't solve the problem you were trying to solve.

Audit Your Integrations and Data Exits

Make a list of every system that talks to your EMR, in either direction. The obvious ones: e-prescribing, labs, payment processor, patient portal. The less obvious ones: your accounting system, your email marketing tool, a pharmacy partner's portal, a Zapier workflow someone built two years ago that's still quietly moving form submissions into Google Sheets.

For each integration, confirm three things. First, is it documented anywhere, or does it live in one staff member's head? Second, what credentials and ownership govern it (whose account, whose email, whose API key)? Third, what happens to the data when the source system goes away?

While you're at it, find out exactly how you get your data out of the current EMR. Read the contract. Some vendors charge extra for export, some limit you to PDF dumps that destroy the structured data, some hold attachments hostage in proprietary formats. Get a test export now, before you're negotiating an exit. Open the files. Confirm that what you thought was structured data actually exports as structured data.

Look at the Data Quality You're About to Inherit

Migrating dirty data into a new EMR doesn't clean it. It just moves the mess. Run a few targeted queries on your current system to find out what you're working with.

Things I'd check:

  • Duplicate patient records (search by last name plus DOB)
  • Patients with no chart activity in 24+ months (active vs. inactive segmentation)
  • Allergy and medication fields that are blank, or marked "see notes"
  • Inconsistent provider names (Dr. Smith, J. Smith, Smith MD all referring to the same person)
  • Free-text fields where structured data should live
  • Orphaned attachments not linked to a current chart

You don't have to fix all of it before migrating. You do need to decide what gets cleaned, what gets archived, and what gets carried over as-is with a clear note that it's legacy data. The decision is easier to make now, calmly, than during a cutover weekend.

Talk to the People Who Actually Use the System

Practice owners and managers see one version of the EMR. The medical assistant who lives in it for nine hours a day sees a different version. Sit with each role for at least an hour. Don't ask "what do you like and not like." Ask them to show you, in real charts, how they handle their five most common tasks. Watch what they actually click. Note where they sigh.

This is also where you learn which staff members have built tribal knowledge that needs to be captured before migration. The front-desk lead who knows the exact sequence of clicks to override a scheduling conflict, the biller who knows which modifier the system silently strips, the nurse who knows that the lab interface drops decimal points if you don't refresh first. If those people leave between now and go-live, that knowledge leaves with them.

Document Compliance and Access

Pull your current user list and audit it. How many active accounts do you have? How many belong to people who haven't worked there in a year? Who has admin rights and why? When was the last time anyone reviewed access logs?

Migration is a natural moment to reset this. Don't just copy the existing user list into the new system. Build the access policy you actually want, role by role, and provision the new EMR against it. Confirm your BAA situation with current and future vendors, and make sure your retention policy for the old system is documented before you turn it off. Talk to your own counsel about retention periods and what you're obligated to keep accessible. The specifics vary by state and by what you've signed.

Build the Migration Brief Before You Pick a Vendor

The output of this audit isn't a decision. It's a brief. A document that tells any vendor you evaluate exactly what you have, what you need, and what would break if it got lost. When you walk into demos with that brief in hand, the conversations change. You stop watching feature tours and start asking specific questions: how does your system handle this custom intake field, what does the export of these compounded prescription records look like, can your scheduling module support this waitlist logic.

For compounding-heavy and concierge practices, the audit usually surfaces requirements that off-the-shelf EMRs were never designed for. That's part of why we built what we built. If you want to compare notes on what a migration brief for a concierge or compounding practice typically looks like, talk to our team and we'll walk you through the templates we use.

Frequently Asked Questions

How long should an EMR audit take before migration?

For a small to mid-size practice, plan on three to six weeks of part-time work spread across your manager, a clinical lead, and a billing lead. Rushing it to a week almost always means you miss workflows that live outside the EMR, and those gaps become emergencies during cutover.

Should we clean our data before or after migration?

Both, but for different things. Clean duplicates, inactive records, and obvious data-entry errors before migration so you're not paying to move junk. Save deeper normalization (standardizing provider names, restructuring free-text fields) for after, when you can do it inside the new system's structure rather than guessing what will map.

What's the single most overlooked item in EMR audits?

Workflows that route around the EMR. Spreadsheets, shared docs, manual exports, side conversations. They never show up in feature comparisons, and they're usually where the real operational knowledge of the practice lives. Find them, document them, and make sure your new system either absorbs them or you've planned a replacement.

Do we need outside help to run the audit?

Not necessarily. A capable practice manager with executive support and time blocked off can do most of it internally. Outside help is worth it when you don't have anyone on staff who can read database exports, or when you've outgrown the current system so badly that internal staff can't see the workarounds anymore. Either way, the audit findings should be owned by the practice, not the vendor selling you the next system.