Choosing an EHR data migration company is one of those decisions that looks reversible on paper and almost never is in practice. Once patient data has moved, the legacy system has been decommissioned, and clinical staff have built new workflows around the new platform, unwinding a bad choice costs far more than making the right one would have. This is not a decision to make on the strength of a polished sales deck.
This guide is for organizations actively evaluating EHR migration services, whether that means comparing two finalists or building a shortlist from scratch. It covers the evaluation criteria that matter, the questions worth asking in vendor calls, the red flags that show up if you know what to listen for, pricing model considerations, and how to get real signal out of a case study instead of a curated success story.
If you want the broader operational framework first, the EHR Data Migration: The Enterprise Guide and the EHR data migration checklist cover the project itself in detail. This guide is about who should be running it.
Two Migrations That Require Different Things From a Partner
Not every EHR migration carries the same risk profile, and the right partner for one situation is not automatically right for another.
A regional health system absorbing three recently acquired practices onto a single Epic instance, each running a different legacy EHR, on a timeline set by the acquisition’s closing date, needs a partner experienced in reconciling multiple source systems at once and running parallel workstreams without losing governance control. A single-site behavioral health practice migrating from an aging on-premise system to a modern cloud platform is smaller in scale but carries its own risk: therapy notes, treatment plans, and assessment data that do not map cleanly using standard clinical terminology and require a team that has specifically handled behavioral health documentation before.
Be clear about which of these your project resembles before evaluating any vendor. A partner with deep multi-site consolidation experience and no behavioral health background is the wrong fit for the second scenario, regardless of general reputation, and the reverse is equally true. The criteria below apply to both, but how heavily each one should weigh depends on which situation you are actually in.
Healthcare-Specific Experience Is Not Optional
The first filter, and the one organizations skip most often, is whether a vendor’s experience is in healthcare data specifically or in data migration generally. These are not the same skill set, and the gap between them does not show up until the project is well underway.
General data migration expertise handles structured data competently. Healthcare data is not uniformly structured. A clinical note may exist as free text in one system and as discrete coded fields in another. Medication data carries dosing logic, frequency rules, and interaction flags that need to behave correctly after migration, not just transfer completely. Problem lists, allergy records, and immunization histories each carry coding standards, ICD-10, SNOMED CT, LOINC, RxNorm, that a generalist IT vendor may not map correctly between source and destination terminologies. A migration that handles structured fields well and mishandles clinical terminology mapping can look successful in testing and create real clinical risk once providers are relying on it.
Infowerks has been doing this work since 1997, which means the question of “have you seen this exact problem before?” usually has a specific answer rather than a hypothetical one. Across that history, the team has worked with more than 150 different healthcare software platforms, which matters less as a number and more as evidence that the migration approach has been tested against genuine platform diversity rather than two or three familiar systems. If your shortlist includes a vendor whose healthcare experience is recent or thin, that is worth weighing heavily regardless of how strong their general technology credentials look.
References From the Same EHR Ecosystem
A reference list full of satisfied healthcare clients is a reasonable starting point and an insufficient one. The reference that actually tells you something is one involving the same source and destination systems you are working with, or as close to it as the vendor can produce.
A migration from Oracle Health (formerly Cerner) to Epic carries a different set of structural challenges than a migration from a legacy on-premise system to a cloud-native platform, and a vendor’s general healthcare experience does not automatically transfer between them. Ask for references in your exact ecosystem: same source platform, same destination platform if possible, or at minimum the same category of complexity, whether that is multi-site consolidation, an acquisition-driven timeline, or specialized documentation requirements.
When you get the reference call, ask the client what went wrong, not just what went right. A reference who can describe a specific problem and how the vendor handled it is more useful than one who reports a flawless project, because flawless reports are rare enough to be a red flag in themselves. If you are evaluating Infowerks, ask us for references in your specific platform pairing directly. We would rather connect you with a client who has been through something close to your situation than offer a generic list.
Methodology and Tooling: Ask to See It, Not Just Hear About It
Most vendors will describe their migration process in a sales call using language that sounds thorough: discovery, mapping, validation, go-live, support. The description is not the methodology. The methodology is the actual document, the actual phase structure, and the actual validation criteria that the team works from on every project. A process that sounds reasonable in the abstract but cannot be shown to you in concrete form is one of the more reliable signals that a team is improvising on a per-project basis rather than working from a tested approach. Infowerks works from an eight-phase framework covering everything from initial source environment audit through post-cutover monitoring, and we walk prospective clients through that structure directly.
Tooling is part of this conversation, but a smaller part than vendors sometimes present it as. AI-assisted mapping and anomaly detection tools genuinely accelerate specific phases of migration work. But tooling without methodology is just faster guessing. What matters more is how the team validates what the tooling produces, and who is qualified to make that judgment call.
Team Composition: Who Is Actually Doing the Work
The proposal you receive during sales conversations is rarely the team that does the work. This matters more in EHR migration than in most data migration contexts because the judgment calls involved are clinical as much as technical. Deciding whether a medication record’s dosing history has translated correctly, whether a problem list entry retains its clinical meaning after terminology mapping, or whether an allergy alert configuration will behave correctly in the destination system requires someone who understands what that data means in a care setting, not just where it lives in a schema. A team composed entirely of data engineers with no clinical informatics background can move data accurately at the field level and still produce a migration that creates clinical risk.
Continuity matters as much as composition. Migration projects that run for months can quietly lose continuity if the team in the proposal is not the team still engaged at go-live, which is worth confirming directly with any partner you are evaluating, including us.
Validation Rigor: What Should Actually Be Checked
Validation is where the most consequential gaps in a migration partner’s capability tend to surface, and it is also the phase most vendors describe least specifically in sales conversations.
A rigorous validation approach establishes a data baseline in the source system before extraction begins, so post-migration reconciliation has something concrete to measure against. It validates field-level mapping against real clinical workflows rather than just confirming that fields transferred, the same distinction that matters across pharmacy and EHR migrations alike: a field can be technically present and functionally wrong. It includes structured reconciliation for high-risk data categories specifically, medication histories, allergy records, problem lists, and any data tied to active clinical decision support rules. And it extends past go-live. Infowerks runs structured monitoring through 30, 60, and 90 days post-cutover, because the errors that surface immediately at go-live are rarely the only ones that matter. Some only become visible once staff have used the new system through a full operational cycle.
A vendor that has only ever discussed validation in the abstract, without a written plan they can show you, has likely not been pressed on it by a previous client, which is itself informative.
What a Strong Answer Sounds Like, Compared to a Weak One
Three questions tend to do the most work in a vendor call.
Asked how they validate clinical data accuracy, a weak answer stays general: thorough testing, quality assurance, multiple review cycles. A strong answer names the specific data categories receiving structured reconciliation and what happens procedurally when a discrepancy is found.
Asked what happens if a problem surfaces after go-live, a weak answer offers reassurance: that is rare, we will fix anything that comes up. A strong answer describes a defined post-go-live monitoring window and a specific example of a problem that surfaced on a past project.
Asked to describe a project where something went wrong, a weak answer claims nothing significant has ever gone wrong or pivots to a success story instead. A strong answer names a specific complication and the structural change made afterward to prevent it from recurring. The willingness to answer this question directly is itself part of the signal.
Red Flags Worth Taking Seriously
A few patterns show up reliably across migration partners that later cause problems, and they are usually visible before the contract is signed if you are listening for them.
A vendor that cannot describe a specific complication from a prior project, offering only general reassurances instead, has either not encountered real complexity or is not willing to discuss it candidly. Neither is a good sign. A team with no clinical or healthcare operations background among the people actually doing the work is a structural risk, not a minor gap. Vague answers about validation methodology, particularly an inability to describe what happens when a discrepancy is found, suggest the process has not been pressure-tested. The absence of any reference in your specific EHR pairing, when the vendor claims broad healthcare experience, is worth probing rather than accepting at face value. And pricing significantly lower than comparable proposals for the same scope is rarely a sign of efficiency. It is more often a sign that something, validation depth, post-go-live support, or scope itself, has been quietly reduced to hit the number.
Questions to Bring Into Your Next Vendor Call
Organized by category so you can use this section directly as a working tool.
- Experience: How many enterprise EHR migrations has your team completed in our specific source and destination systems? How many healthcare software platforms has your team worked with directly?
- Compliance: What specific HITRUST certification level do you hold, and can you provide current documentation? How does your compliance program address the 2026 HIPAA Security Rule requirements?
- References: Can you provide a reference in our exact platform pairing, and can I speak with that client directly?
- Methodology: Can you walk me through your methodology document, not summarize it? What are the entry and exit criteria for each phase?
- Team: Who specifically will be assigned to this project, and what is their healthcare data background? Will this be the same team through go-live?
- Validation: What does your validation plan look like in writing? What percentage of records are reviewed versus sampled? What is your process when validation finds a discrepancy?
- Post-go-live support: What does your support window look like after cutover? Can you describe a specific issue that surfaced after a past go-live and how it was resolved?
- Pricing: What is explicitly excluded from this proposal? What triggers a change order, and how have you handled scope changes on past projects?
Pricing Models: Fixed-Fee vs Time and Materials
Most EHR migration engagements are priced one of two ways, and each comes with a different set of questions worth asking regardless of which model a vendor proposes.
| Fixed-Fee | Time and Materials (T&M) | |
| Predictability | High. Total cost is known upfront. | Lower. Final cost depends on the hours actually required. |
| Best fit for | Well-scoped projects with a defined data environment and clear boundaries | Projects with significant unknowns, legacy systems with undocumented complexity, or evolving scope |
| Risk if the scope is underestimated | Vendor absorbs the risk, which can incentivize cutting corners on discovery | Client absorbs the risk through extended billing |
| What to ask about | What is explicitly excluded from the fixed price, and what triggers a change order | What governance exists to control hours, and how progress is reported against the budget |
| Common failure mode | A narrowly scoped fixed price that does not survive contact with real data complexity | An open-ended engagement with no clear endpoint or accountability for delays |
Neither model is inherently better. A fixed-fee arrangement works well when the data environment has been thoroughly assessed before pricing, because the vendor has enough information to price the actual risk rather than guess at it. A time and materials arrangement makes more sense for complex, less-documented environments where forcing a fixed number too early creates an incentive to underscope the discovery phase just to win the bid. Infowerks scopes pricing based on what the discovery phase actually finds in your environment, rather than defaulting to one model, and we can walk you through which structure makes sense once we understand your specific source and destination systems.
What to Ask For in a Case Study
A case study handed to you as a polished document is marketing material. A case study you can actually interrogate is due diligence. Request the specific source and destination systems involved, the data volume and historical depth migrated, the actual timeline from kickoff to go-live, and what complications arose and how they were resolved, since a case study with no friction at all is less informative than one that shows how a real problem was handled. If at all possible, ask to speak directly with the referenced client rather than relying on the vendor’s written summary.
A migration partner confident in their work will not resist this level of scrutiny. We are glad to walk through specific Infowerks case studies in detail, including what went wrong on a given project and how it was handled, rather than offering only the polished version.
Frequently Asked Questions
What is the difference between HITRUST e1, i1, and r2 certification?
The three tiers reflect increasing levels of assessment rigor. e1 is appropriate for lower-risk vendor relationships. i1 is the level most health plan and hospital system contracts specify by default. r2 is the highest tier, typically required for federal contractor work, PBM contracts, and large health system integrations. Ask a prospective vendor which specific level they hold rather than accepting "HITRUST certified" as sufficient on its own.
How long does an enterprise EHR data migration typically take?
Timeline depends heavily on data volume, the number of sites and specialties in scope, and how much historical data needs to migrate versus archive. Smaller, single-instance migrations can run a matter of weeks. Enterprise health system consolidations involving multiple acquired sites can take several months, with discovery and governance work alone consuming a meaningful portion of that timeline.
Should we choose a fixed-fee or time and materials pricing model?
It depends on how well your data environment has been assessed before pricing. Fixed-fee works well when the scope is genuinely well understood. Time and materials is often the more honest model for complex, less-documented legacy environments, since forcing a fixed number before discovery is complete creates pressure to underscope the project. Ask any vendor how they have handled scope changes on past engagements, regardless of which model they propose.
What is the biggest mistake organizations make when selecting an EHR migration partner?
Treating data migration experience and healthcare data migration experience as equivalent. A vendor can be highly competent at moving structured data and still lack the clinical terminology knowledge, coding standard familiarity, and healthcare operations background required to migrate EHR data without introducing clinical risk. The team composition behind a proposal matters as much as the proposal itself.
How do we verify a vendor's compliance claims instead of just taking their word for it?
Ask for documentation, not assurance. Request current HITRUST certification documentation and the specific level held. Ask how the vendor's practices align with the 2026 HIPAA Security Rule requirements around multi-factor authentication, encryption, and breach reporting timelines. A vendor with a genuine compliance program will have this documentation ready. One without it will offer general reassurance instead.
In Conclusion
The decision in front of you is not really about comparing feature lists or process diagrams. It is about determining which vendor has handled the specific complexity your migration will involve, and which one has a team and validation process rigorous enough to catch problems before they reach your clinicians and patients.
Infowerks has been doing healthcare data conversion work since 1997, across more than 150 different software platforms, with a track record that includes zero data breaches across that history. That depth shapes how migrations are scoped, validated, and supported, including structured monitoring through the first 90 days after go-live rather than treating go-live as the finish line.
Evaluating partners for an EHR data migration?
Talk to Infowerks about your specific source and destination systems, what a realistic timeline and validation plan would look like, and references in your exact platform pairing.
Schedule a Consultation by filling out this form or calling us at 702-914-9910.
Don’t forget to download this checklist and bring it into your next conversation.
This article was written by Shristi Patni and reviewed by Jeff Deitch, CEO and Co-Founder of Infowerks Data Services, with nearly 35 years of experience in healthcare data interoperability.
