There is a story that repeats itself in almost every large EHR implementation, and it is almost never told honestly afterward. The project was scoped, the vendor was chosen, the timeline was set, and somewhere around the halfway mark the whole thing quietly doubled in cost and slipped a quarter. When the postmortem happens, the blame lands on the software, the vendor, the consultants, the change management. It rarely lands where it belongs: on the data. The system worked. The data you poured into it did not.
This matters because the conclusion most organizations draw is the wrong one. They decide the platform was too complex, or the integrator underperformed, and they carry that lesson into the next project unchanged. The actual failure happened before the migration started, in a data estate nobody had looked at closely. Epic and Oracle Health sell mature, well-understood platforms. The reason the projects overrun is that the records being moved into them were built over decades by people who were not thinking about a future migration, and no one checked their condition before committing to a date and a price.
The Software Works. Your Data Doesn't.
Walk into any organization that has been operating for more than a few years and the clinical, financial, and operational data has the same set of problems, in different proportions. The same patient exists three times under three spellings, with three medical record numbers and no reliable way to know they are the same person. Critical fields that the target system treats as structured and required live in your source system as free text, or as a note someone typed into a comment box, or as nothing at all. Interfaces that were supposed to keep two systems in sync stopped working at some point and nobody noticed, so the data diverged silently. Legacy encodings, retired code sets, discontinued departments, and merged facilities all left residue that is still sitting in the tables.
None of this is a sign of a badly run organization. It is what accumulated data looks like everywhere. The problem is that a migration is the moment all of it comes due at once. The target EHR does not tolerate ambiguity the way your old systems did. It expects a clean patient identity, a specific structure, a defined code set, and a field populated where it says the field is required. Every place your data falls short of that expectation is a decision someone now has to make, under time pressure, in the middle of the project.
Why the Overrun Is Invisible Until It Isn't
The cruelty of this pattern is its timing. The data problems do not surface during scoping, when you still have leverage. They surface during mapping and validation, after the contract is signed, after the go-live date has been communicated, after the budget has been approved by a board that was told a number. By then the questions are no longer abstract. Which of these three duplicate patients is real? What do we do with the two million records that have no value in a field the new system requires? How do we transform a code set that was retired in 2014 into the one Epic expects? Each answer is real work, and each was invisible when the price was set.
This is how a fixed-price migration becomes a series of change orders, and how a go-live slips from spring to fall. It is not that anyone estimated dishonestly. It is that the estimate was built on an assumption about the data that no one had tested, because testing it was not part of the plan. The scope was written as if the data were ready. The data was never ready, and there was no step in the process designed to find out before it mattered.
Lift and Shift Is a Decision to Pay Later
Faced with this, the tempting move is to defer it: move everything as-is, get to go-live, and clean it up later. In most industries that is merely expensive. In healthcare it is worse than that, because the data is clinical. A duplicate patient record is not a data-quality nuisance; it is a chart that a clinician may make a decision from. A medication or allergy that migrated into the wrong field, or failed to migrate at all, is not a formatting error; it is a patient-safety exposure that now lives inside a system everyone trusts more than the one it replaced. Moving unexamined data into a modern EHR does not make it better. It gives bad data a clean interface and the authority of a new platform, which is the most dangerous thing you can do with it.
"Clean it up later" also never happens on the terms you imagine. After go-live, the organization is exhausted, the budget is spent, and the appetite for touching the system again is gone. The cleanup becomes a permanent backlog, and the compromises made under deadline become the permanent state of the record. The decision to lift and shift is really a decision to carry the mess forward indefinitely, now at clinical stakes and inside a system that is far harder to correct after the fact.
Audit Before Contract
There is a cheaper path, and it runs in the opposite order from how most of these projects are sequenced. Before you sign the migration contract, audit the data estate. Not a survey, not a self-assessment, an actual examination of the clinical, financial, and operational records: how complete they are, what quality they are in, how they are structured, and how ready they are for the interoperability the target system assumes. The point is to know the true condition of the foundation before you commit a price and a date to moving it.
An honest audit changes three things. First, it reprices the migration truthfully, because the estimate is now built on the data's real condition instead of a hopeful assumption. Second, it gives you leverage in the vendor and integrator conversation, because you can scope the work against known facts rather than discovering the facts as change orders. Third, and most valuable, it separates the data you should move from the data you should not, so you are not paying to transform and validate records that have no business in the new system at all.
An audit is also the responsible way to handle protected health information, because it forces the questions about identity, completeness, and accuracy to be answered deliberately, up front, under a Business Associate Agreement, rather than improvised in the middle of a live migration. The discipline that protects patients and the discipline that protects the budget turn out to be the same discipline.
None of this is an argument against Epic or Oracle Health. They build platforms that will run a health system well for a long time. The argument is narrower: the platform is not where your migration will fail. It will fail in the data layer, in the records nobody looked at until it was too late to do anything but pay. The organizations that treat the data as the project, and audit it before they sign, are the ones whose migrations come in near the number they were promised. The ones that treat the data as a detail find out what it actually costs at the worst possible time to learn it.
Look at the data first. It is the one part of the project you can still change the price of.
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.