Momo AnalyticsResearch · February 14, 2026
Pitfalls to watchout for in an EMR Migration
A brief account of how health records can be lost, and how to catch it before go-live
Abstract
Electronic medical record migrations are usually scoped, budgeted, and staffed around the structured data: demographics, encounters, orders, results. That part is tractable - it usually maps and validates from source to target in a relatively clean manner, and it’s where the most attention is. It is also not where migrations fail.
The failures cluster around the unstructured and semi-structured content: scanned documents, free-text clinical notes, attachments with inconsistent naming, records that span two source systems because of a historical merge, and edge-case patients whose charts don’t fit the schema anyone designed for. This piece is a field-level account of that remainder, based on a legacy-to-Epic migration carried out for a specialized inpatient/outpatient provider, with no material data elements lost.
1. Structured data is not the hard part
Demographics, billing codes, scheduling records, lab results with defined units - these map field-to-field with a mapping document and a validation script. Reconciliation is mechanical: row counts in, row counts out, spot-check a sample, sign off, etc. Most migration vendors are competent at this part, and most migration budgets assume this is the hard part when it might not be.
2. The biggest challenges are roughly in four places
Scanned and attached documents. Referral letters, consent forms, external lab reports, faxed records from other providers - these arrive as PDFs and images with no consistent naming convention, no reliable patient-ID embedding, and no guarantee the scan quality supports OCR. A migration that treats these as “attachments to carry over” without building a parser for the metadata inside them will either lose the linkage between the document and the correct patient, or lose the document’s context (what it is, when it was created, who authorized it).
Free-text clinical notes. Notes written over a decade by different clinicians, in different formats, sometimes with embedded structured data (vitals, medication lists) that was never captured as structured data in the first place - because the old system didn’t have a field for it. Migrating the text is easy. Migrating it so it’s usable in the new system, searchable, and correctly associated with the encounter it describes, is not.
Records that span a system boundary. Any provider with enough history has usually been through at least one prior system change, a merger, or a department that used its own local tool before being folded into the main EMR. Patients who existed before that boundary often have two partial charts that were never fully reconciled. A migration script that assumes one patient equals one clean source record will silently create duplicate or fragmented charts in the new system.
Edge-case patients. Deceased patients, patients under guardianship, patients with legal holds on their records, patients who were seen once a decade ago and never came back - these are exactly the records most likely to be handled by a generic rule that doesn’t apply to them, because they’re rare enough that nobody wrote a rule for them at all.
The mapping document tells you where 95% of the data goes. It says nothing about the 5% that doesn’t fit the document - and that 5% is disproportionately the clinically sensitive part: notes, attachments, and edge-case charts.
3. How we caught the problems
Three things, in order of how much they mattered:
Custom parsers for document and note metadata, written specifically for this migration rather than relying on the receiving system’s generic import tool. A generic importer will take what you give it and place it somewhere. It won’t tell you when a document has no reliable patient linkage, or when a note references an encounter that doesn’t exist in the structured data. A custom parser can be written to fail loudly on exactly those cases, instead of succeeding silently in the wrong place.
Reconciliation against the old system, in addition to the mapping document. Validating that the migration matches its own plan only proves the plan was executed. It doesn’t prove the plan was complete. The only real check is comparing what’s live in the new system against what a clinician can still see in the old one, chart by chart, for a sample large enough to catch systemic issues rather than one-off ones.
A rebuild-from-scratch approach on the pipeline itself. Treating the migration pipeline as versioned, re-runnable code - not a one-time manual process - meant that when an issue was found in the reconciliation step, the fix was a code change and a re-run, not a manual patch applied under deadline pressure to a production system.
4. So what does this mean for anyone scoping a migration?
Ask your migration partner, specifically: how are unstructured documents linked to patient records, and what happens when that link is ambiguous? How are free-text notes validated post-migration - against a schema, or against a human reading the original? What is the plan for patients who existed before a prior system boundary? If the answers are generic (“the platform handles that”), the risk hasn’t been scoped - it’s been assumed away.
The structured 95% of a migration is a project management problem. The unstructured 5% is an engineering problem, and it’s the one that determines whether a hospital’s institutional memory survives the move intact.