You have decided to move to Epic or Oracle Health. Maybe the old system is being sunset, maybe a merger forced the question, maybe leadership finally lost patience with the one you have. Whatever the trigger, the next step is a conversation with the vendor, and that conversation is going to assume you know things about your own data that, in almost every organization the firm has seen, no one actually knows. The gap between what the conversation assumes and what you can answer is where the project starts going sideways, before a single record has moved.
The uncomfortable truth is that the vendor and their implementation partner scope the project from what you tell them. They are not going to audit your data before they quote you; that is not their job at that stage, and you are not paying them to. So the timeline and the price get built on your description of your data, and your description is usually optimistic, because you are describing what you think is in there, not what is actually in there. When the two diverge, and they always diverge, the difference becomes change orders and schedule slips that land on you.
What They Actually Need, in Plain English
Strip away the acronyms and the onboarding checklists, and what a modern EHR needs from you before a migration falls into five categories. None of them is technical in the sense that a non-technical leader can't understand it. All of them are things you should be able to speak to before you are sitting across from a vendor.
One: a clean patient identity. The single most important thing you bring to an EHR is the ability to say, with confidence, that one human being corresponds to one record. If the same patient exists multiple times under different spellings, different identifiers, or different facilities, the new system inherits that confusion and, worse, may merge or split records in ways that are hard to unwind later. Before the conversation, you should know how many patients you actually have, how you know that, and how bad your duplicate problem is. Most organizations have never measured it.
Two: structured data where they expect structure. The target system treats certain fields as discrete, required, and coded, allergies, medications, problems, results. If those live in your source system as free text, as scanned documents, or as a note someone typed into a comment box, they are not migration-ready. Knowing which of your critical fields are genuinely structured and which only look structured is a large part of what determines the real scope of the work.
Three: current, mapped code sets. Clinical and financial data is only portable when it speaks a shared vocabulary, the standard terminologies and code sets the target system expects [VERIFY: confirm the specific code systems and versions Epic / Oracle Health require for your data types]. If your data uses a retired code set, a homegrown one, or a version several revisions out of date, every one of those values has to be mapped to the standard the new system speaks. You do not need to build that mapping before the vendor conversation, but you do need to know where you stand, because it is one of the largest hidden costs in any migration.
Four: a known inventory of your source systems and interfaces. Almost no organization runs on a single system. Data lives in a primary EHR, a billing system, a lab system, a handful of departmental applications, and a set of interfaces, HL7 feeds, FHIR endpoints, flat-file exports, that move data between them [VERIFY: confirm which interface standards and endpoints apply to your environment]. Before the conversation, you should be able to name every system that holds data you care about, say which one is authoritative when they disagree, and know which interfaces are actually working versus which quietly stopped years ago.
Five: a decision about scope. Not all of your data should move, and the assumption that it must is how migrations balloon. How much history do you actually need in the live system? What is your legal medical record, and where does it live? Which data can be archived rather than migrated? These are governance decisions, not technical ones, and making them before the vendor conversation is what keeps you from paying to transform and validate records that never needed to move at all.
The Questions You Should Be Able to Answer Before the Meeting
Here is the short version, the questions a readiness process exists to answer, and the ones you do not want to be improvising in front of a vendor. How many patients do we actually have, and how many duplicates? Which of our critical clinical fields are truly structured and coded, and which only appear to be? What terminologies and code sets is our data in today, and how far are they from what the target expects? What are all the systems and interfaces that hold data we need, and which one wins when they conflict? And how much of this data actually needs to migrate versus be archived? If you can answer those cleanly, the vendor conversation is a negotiation. If you can't, it is a discovery exercise that you are funding without knowing the bill.
Readiness Is Cheaper Than Discovery
The reason to answer these questions before the vendor conversation, rather than during the implementation, is that the two happen at very different prices. Answered up front, in a focused readiness engagement, the work is bounded and advisory: you learn where you stand and you walk into the vendor meeting with facts. Discovered later, during a live implementation, the same questions get answered by the most expensive people on the project, under deadline, as change orders, with your go-live date hanging on the outcome. Same questions, an order of magnitude difference in cost and leverage.
This is the whole logic of doing readiness as its own step. It is advisory, it is short, and it produces one thing: a clear picture of what data you have, in what shape, and what has to be true before an Epic or Oracle Health conversation can be productive. It is not the migration, and it is not a commitment to one. It is the difference between showing up to the most consequential vendor negotiation your organization will run this decade prepared, and showing up hoping the data is better than you fear.
The vendors are not the adversary here. Epic and Oracle Health will do exactly what you scope them to do. The question is whether you scope it from knowledge or from optimism. Everything they need from you is knowable before you walk in. The organizations that make it knowable first are the ones whose implementations look nothing like the horror stories. Do the readiness work before the conversation, and the conversation gets a great deal shorter and a great deal cheaper.
NoBullStrategy is a strategy and transformation practice for mid-market operators at inflection points. Its healthcare practice runs data-first EHR work: healthcare data audits, EHR readiness consulting, and spec-to-spec migration to Epic and Oracle Health. NoBullStrategy does not practice medicine or provide legal advice.