Every industry has a comfortable lie it tells about data migration, and in most of them the lie is survivable. The lie is that you can move the data as it is, get to go-live, and sort out the mess later. In retail, in logistics, in most of financial services, this produces a bad quarter and a cleanup project. In healthcare, the same shortcut moves records that clinicians make decisions from, and the mess you deferred is now sitting inside a chart, wearing the authority of a brand-new system that everyone trusts more than the one it replaced. That is why the phrase lift and shift should stop a clinical data project cold.
The honest alternative has a less exciting name. It is called spec-to-spec migration, and the name is the whole method: you map every field from the specification of the source system to the specification of the target EHR, define exactly how each one transforms, prove that it landed correctly, and let nothing cross that has not been through the whole process. It is slower than lift and shift. It is also the only version that produces a record you can actually trust when a clinician opens it.
Why Lift and Shift Is Malpractice in Healthcare Data
Lift and shift treats data as content to be copied, when clinical data is meaning to be preserved. A row in your source system is not just characters in a field. It is an allergy that will or will not fire an alert, a medication that will or will not be reconciled, a result whose units determine whether a value looks normal or alarming. When you copy that row into a system with a different structure, a different code set, and different rules about what a field means, you are not moving information. You are re-encoding it, and if you do that without deciding how each field should translate, the system decides for you, silently, and sometimes wrong.
The failures are not hypothetical, and they are not evenly distributed toward the harmless. An allergy that lands in a free-text note instead of the coded allergy field no longer triggers the interaction check it used to. A medication with a units mismatch reads as a different dose. A duplicate patient that was tolerable in the old system becomes two charts a clinician might see separately. None of these are exotic. They are the ordinary consequences of moving data faster than you understood it. That is the sense in which lift and shift is not just risky but irresponsible: it accepts clinical exposure in exchange for schedule, and hides the trade inside a technical decision nobody clinical ever got to weigh in on.
What Spec-to-Spec Actually Means
Spec-to-spec is the discipline of refusing to let any field move on autopilot. It starts from the two specifications, the exact structure and rules of the source system, and the exact structure and rules of the target EHR, and it treats the gap between them as the actual work. Every field in scope gets four things attached to it before it is allowed to migrate, and a field that is missing any of the four does not move until it has them.
A mapping. Where does this source field go in the target, and is the relationship one-to-one, many-to-one, one-to-many, or does it have no home at all? A surprising amount of source data maps to nothing in the target, and discovering that deliberately is far better than discovering it as an error.
A transformation rule. How does the value change on the way across? Units get converted, code sets get remapped to the standard the target expects, formats get normalized, free text gets parsed into discrete fields where it can be and flagged where it can't. The transformation rule is the explicit statement of how meaning is preserved, and writing it down is what makes it reviewable instead of buried in a script.
A validation rule. How will we know it landed correctly? For every transformation there is a corresponding check: counts reconcile, values fall in expected ranges, coded fields resolve to valid codes, a clinical sample matches the source. If you cannot state how you would detect that a field migrated wrong, you have not finished designing the migration of that field.
An owner and a status. Someone is accountable for each field's mapping being correct, and each field has a visible state, mapped, transformed, validated, signed off. This is the same accountability discipline the rest of the practice runs on, applied to data: owned and measured, or it reverts. A field with no owner is a field nobody will answer for when it turns out wrong.
Validation Is the Product
The part that separates a real migration from an expensive copy is validation, and it is the part most compressed timelines quietly cut. You do not trust a migration because the job finished without errors. You trust it because you can prove, field by field and record by record, that what is in the target means the same thing as what was in the source. That proof is not a formality at the end. It is the deliverable. Everything before it is just moving data; validation is what tells you whether you moved it correctly.
In practice that means reconciliation at every level: totals and counts that have to match, value distributions that have to look right, coded fields that have to resolve to legal codes in the target, and clinical spot-checks where someone qualified opens a sample of real charts and confirms they read correctly. And it means gates, points in the process where migration stops until the validation for that phase has passed and been signed off. The gates are not bureaucracy. They are the mechanism that keeps an unvalidated batch from becoming the permanent record because the calendar wanted it to.
Cutover Is a Clinical Event, Not a Technical One
The final step people underestimate is the cutover itself, the moment the organization stops running on the old system and starts running on the new one. Treated as a technical switch, it becomes the single riskiest hour of the project. Treated correctly, it is a planned clinical event with a rehearsed sequence, a defined point of no return, a reconciliation of anything that changed during the transition, and a contingency for what happens if something is wrong after the switch. Spec-to-spec discipline earns its value here: because every field was mapped, transformed, and validated ahead of time, the cutover is the execution of a known plan rather than a leap you are hoping survives.
This is also why the migration is structured in phases behind a discovery gate rather than sold as one monolithic price. The discovery phase establishes the two specifications and the true scope of the gap between them; only then can the migration be planned honestly, in milestones, each with its own mapping, transformation, validation, and sign-off. Anyone who quotes you a full clinical migration as a single fixed number before the specifications are understood is quoting you a lift and shift with better marketing.
Throughout, the work is run with the discipline the data demands: executed under a Business Associate Agreement, with PHI handled deliberately at every stage, and with the clear boundary that this is data engineering, not the practice of medicine and not legal advice. The clinical and legal judgments belong to the people qualified to make them. What spec-to-spec guarantees is that when they make those judgments, they are looking at a record that means what it is supposed to mean.
Lift and shift is faster, and in healthcare that speed is borrowed against patient safety and paid back with interest. Spec-to-spec is the version that treats the data with the seriousness a clinical record deserves: nothing moves unexamined, everything is proven, and the record you hand the clinicians is one you can stand behind. It is more work. It is the only honest version of the work.
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.