Choosing a new EHR is only half the project. The harder operational question — the one that gets decided too late, under deadline pressure — is what happens to every patient record sitting in the system being replaced. A practice cannot simply unplug the old EHR the day the new one goes live. Historical data has to go somewhere, and the option chosen determines whether a clinician can find a patient's medication history six months from now, or whether that history quietly becomes inaccessible.
This is a decision with clinical, legal, and cost consequences, and it is distinct from picking a vendor or budgeting the implementation itself. Below are the three real paths practices take with legacy data, the failure modes of a rushed migration, and what record-retention obligations mean once the switch is complete.
Three ways to handle legacy EHR data
Practices generally choose from three approaches, or blend them:
- Full data migration. Every record is extracted, mapped to the new system's data structure, and loaded in — fully searchable and editable inside the new EHR. This is the most complete option but also the most resource-intensive, because it requires careful field-by-field mapping between two systems that were rarely designed to talk to each other.
- Read-only legacy system access. The old EHR is kept running in a locked-down, view-only state. Clinicians can look up historical notes when needed, but nothing new is entered there. This avoids the cost and risk of migrating every record, though it means staff are working across two systems instead of one, which has its own workflow cost.
- Archiving or extraction to a static format. Inactive charts are pulled out of the legacy system and stored separately, sometimes as PDF-style documents, sometimes in a purpose-built clinical data archive that keeps the material searchable and viewable (but not editable) and can be decommissioned from the vendor's live infrastructure. This is typically the lowest-cost route for records that are rarely touched, and it lets a practice stop paying to keep an old system online. The tradeoff with a plain PDF conversion is that structured data — the kind that can be queried, filtered, or fed into clinical decision support — can be flattened into a document that a person can read but a system can no longer search.
Most practices end up with a hybrid: actively-used patient data migrates into the new EHR, while older or inactive charts move to a compliant archive. The right split depends on how much of the legacy panel is still being actively treated versus how much is closed or transferred out.
Why "dirty" migrations are the real risk
The technical failure mode to plan around is not usually a wholesale data loss event — it is a partial one that goes unnoticed. When field mapping between two EHRs is incomplete, specific categories of information are the ones that tend to disappear or get garbled: medication dosages read incorrectly, lab result flags stripped out, allergy codes dropped entirely. None of these show up as an error message. They show up months later, when a clinician is working from a record that looks complete but isn't.
That has downstream consequences beyond data hygiene:
- Clinical risk. Drug-interaction alerts and allergy flags depend on structured data arriving intact. A migration that silently drops or garbles those fields removes a safety check clinicians are relying on being there.
- Compliance exposure. Protected health information moved outside a secure, access-controlled pipeline — even briefly, even by accident — creates HIPAA exposure independent of whether any record was actually lost.
- Operational disruption. A migration that is not sequenced carefully can take scheduling, clinical documentation, or billing offline mid-transition, which is its own cost separate from the data itself.
- Workaround habits. When staff hit missing or wrong data in the new system, they build workarounds rather than reporting the gap — and those workarounds can keep degrading data quality long after the migration project is officially closed.
The practical defense is validation before and after the cutover: sampling a meaningful percentage of migrated charts against the source record, specifically checking medication lists, allergies, and lab values rather than just confirming the record count matches.
What record retention still requires after the switch
Switching systems does not reset a practice's record-retention clock. Whatever period a state requires records to be kept — and requirements vary by state, and often by patient age, with longer minimums for minors' records — still applies to data sitting in a decommissioned legacy system or an archive, exactly as it would if the system were still live. Two obligations carry forward regardless of which of the three options above a practice picks:
- Accessibility. Records have to stay retrievable for continuity of care, audits, legal discovery, and patient access requests — a read-only legacy login or an archive lookup both satisfy this, but a system nobody can log into anymore does not.
- Security. Wherever the data physically lives — live EHR, frozen legacy instance, or third-party archive — it still has to meet the same HIPAA security and privacy obligations it did on day one. Decommissioning a system does not decommission the compliance requirement attached to the data inside it.
Before finalizing which legacy-data approach to use, it is worth confirming the specific retention period that applies under Arizona requirements for the practice's patient mix, since that number should shape how long read-only access or archive access needs to stay live — not just how the initial migration gets built.
The practical takeaway
The migrate-vs-archive-vs-read-only decision is not really about which is "better" in the abstract — it is about matching the option to how the data will actually be used going forward, then verifying the result rather than trusting that a completed data transfer means a correct one. A practice evaluating EHR data migration and switching needs a plan for legacy data before cutover day, a validation step that checks the fields that actually matter clinically, and a clear answer for how long that legacy data has to remain accessible under Arizona's retention rules. Getting a qualified vendor match for the migration and archiving side of a system switch is a matter of finding the right operational partner for that specific piece of work — not a substitute for a practice's own compliance and clinical review.