Decommissioning a Legacy EHR: Archives, Retention, and Continuity

Every health system that replaces its EHR eventually inherits the same unglamorous project: what happens to the old one. The new platform gets the go-live parties, the steering committees, and the change-management budget. The legacy system that used to run the hospital gets a shrinking support contract, a vendor that would rather stop maintaining it, and a legal obligation to keep its data retrievable for years — sometimes decades — after the last clinician logs out.

Decommissioning a legacy EHR is not a single event. It is a governed transition from “production system” to “retained record,” and the organizations that get it wrong tend to discover the gap at the worst possible moment: a subpoena, an audit, a malpractice claim, or a patient who needs a decade-old lab result and finds that nobody can retrieve it. This piece walks through what a legacy EHR decommissioning actually involves — what has to be retained, what a read-only archive replaces, how vendor sunset timelines complicate the schedule, and the governance steps that keep patient-record continuity intact once the old system goes dark.

What does it mean to “decommission” an EHR, exactly?

Decommissioning is the structured retirement of a system that is no longer used for active patient care, replaced by a governed archive that preserves the ability to retrieve, audit, and disclose the data it once held. It is distinct from simply turning a server off. A hospital that replaces its inpatient EHR still has a legal and operational obligation to produce records from the old system — for continuity of care when a returning patient’s history predates the cutover, for medical-legal discovery, for payer audits, and for regulatory reporting that references historical encounters.

That obligation does not require keeping the legacy system running in production. Most organizations instead extract the data into a dedicated archival platform, validate that the extraction is complete and clinically accurate, grant appropriately scoped read-only access to the people who need it, and then formally retire the source system — including its licensing, hosting, and interface contracts. The archive, not the legacy EHR, becomes the system of record for that historical data going forward.

How long does the data actually have to be kept?

This is the question that trips up the most projects, largely because of a persistent misconception about HIPAA’s role. HIPAA does not set a retention period for medical records themselves. The rule most people are thinking of — the “six-year rule” — applies to HIPAA compliance documentation: policies, procedures, risk assessments, training records, and similar evidence that a covered entity followed the Privacy and Security Rules. It does not govern how long a clinical chart has to be kept.

Medical record retention is instead governed primarily by state law, and HIPAA does not preempt those state requirements. Retention periods vary considerably by state and by record type — common minimums for adult patient records fall in a roughly seven-to-ten-year range in many states, but organizations should confirm the specific requirement in every state where they operate rather than assume a single figure applies nationwide. Records for minors are frequently subject to longer holds, often tied to reaching the age of majority plus an additional statutory window, which in practice can mean records for a patient who was an infant at the time of care need to be retrievable twenty-plus years later.

Federal requirements layer on top of state law for organizations that participate in Medicare or Medicaid. Under the Medicare Conditions of Participation for hospitals, medical records must be retained in their original or legally reproduced form for a minimum of five years, and the hospital must maintain a system that allows for timely retrieval — a floor, not a ceiling, since state law or other federal rules frequently require longer.¹ When multiple retention rules apply to the same record, the standard practice is to retain for whichever period is longest, and to document that decision so the rationale is available if it is ever questioned.

None of this is a substitute for organization-specific legal review. Retention schedules for a legacy EHR decommissioning project should be set jointly by legal counsel, health information management (HIM) leadership, and compliance — not derived solely from a vendor’s default archive configuration or a generic industry checklist.

What does a read-only archive actually replace?

A common point of confusion is the difference between “active archiving” and full decommissioning. Active archiving moves rarely used but still-relevant data out of a production system to keep that system faster and cheaper to run, while the original system stays live. Decommissioning goes further: it closes out the legacy system entirely once its data has been migrated into a governed archive that can stand on its own as the system of record.

That archive needs to reproduce several capabilities the legacy EHR used to provide, not just store a data dump:

• Retrieval by patient, encounter, or document type — the same coding and indexing capability regulators expect of an active medical record system, so a HIM request for a specific chart doesn’t require someone to page through raw database exports.
• Audit logging on who accessed archived records and when, since access to archived PHI is still subject to the same HIPAA Security Rule access-control and audit obligations as an active system.
• Legal hold support — the ability to flag specific patients’ records so they cannot be purged on the normal retention schedule if they become subject to litigation, a malpractice claim, or a regulatory inquiry.
• Disclosure and release-of-information workflows so HIM staff can produce records for patient requests, subpoenas, or continuity-of-care transfers without needing separate access to the retired production system.

Skipping any of these in favor of a bare data export is a common failure mode. Health information management professional guidance on legacy system retirement treats this as an information-governance problem, not a storage problem — the goal is a system that can still answer “who has this patient’s 2019 discharge summary, and can we produce it in a legally defensible form” years after the original EHR is gone.²

Why vendor sunset timelines complicate the schedule

Legacy EHR vendors have limited incentive to keep supporting a system a client is actively replacing, and that creates real scheduling pressure. A few patterns show up repeatedly:

• Support and hosting contracts wind down on the vendor’s timeline, not the archive project’s. If the legacy system is vendor-hosted, the health system may be paying escalating fees for a shrinking support tier, giving the vendor leverage to push for a faster exit than the archive validation work can safely accommodate.
• Interface and integration knowledge leaves with staff turnover. The people who understand a legacy system’s data model and quirks are often the same people who were reassigned or left once the new EHR went live, which makes late-stage extraction problems harder to diagnose the longer decommissioning drags on.
• Licensing costs for “read-only” or “view-only” access modes vary widely by vendor, and some legacy contracts do not include an inexpensive long-term read-only tier at all — meaning the true cost comparison is often between paying for continued full licensing versus investing upfront in a third-party archival migration.

The practical response is to negotiate the sunset timeline explicitly rather than let it default to the vendor’s preference: build in contractual milestones for data extraction validation, keep the legacy system in a limited read-only state until a third-party audit confirms the archive is complete and accurate, and avoid the common mistake of severing the source system’s access before HIM and compliance have signed off — since re-extracting from a system that has already been powered down is far harder, and sometimes not possible, if a data gap is discovered later.

What continuity risks does decommissioning create?

Two continuity risks tend to surface after a legacy system goes dark, and both are more expensive to fix retroactively than to plan for upfront.

Patient-care continuity. A returning patient whose relevant history sits in the legacy system needs that history visible to the clinician treating them today, whether through a migrated summary in the active EHR or a documented, fast path for clinical staff to pull an archived record. Organizations that migrate only a narrow recent-data window into the new EHR — a common and reasonable approach — need a clear, fast process for clinicians to request older archived records rather than an informal understanding that “someone in HIM can probably find it eventually.”

Legal and regulatory continuity. Malpractice statutes of limitations, payer audit lookback periods, and government investigations can all reach back to encounters that predate a system replacement by years. An archive that cannot produce a complete, audit-trail-intact record on short notice creates real legal exposure — not just an inconvenience — if litigation or an audit surfaces after the legacy system has been fully retired and institutional memory of its data model has faded.

Both risks point to the same governance requirement: decommissioning should be planned as a data-continuity project with legal, HIM, clinical informatics, and compliance stakeholders at the table from the start, not handed to IT alone as an infrastructure cleanup task once the new EHR is stable.

What does a defensible decommissioning process look like?

Guidance on legacy system retirement generally converges on a similar sequence, adapted to the scale of the system being retired:

1. Inventory and dependency mapping. Identify every interface, downstream report, and department still pulling data from the legacy system before assuming it can be turned off — a system that “nobody uses anymore” often still feeds a billing extract or a state reporting feed that nobody remembers configuring.
2. Retention and legal-hold determination. Work with legal counsel and compliance to set the retention schedule per record type and state, and identify any patients already under legal hold whose records need special handling regardless of the general schedule.
3. Extraction and validation. Migrate data into the archival platform, then validate both technical completeness (record counts, document types, coded data reconciled against the source) and clinical usability — whether a HIM specialist pulling an archived chart can actually make sense of what they’re looking at.
4. Access governance. Define who can access the archive, under what circumstances, and with what audit logging, mirroring the access-control discipline applied to the active EHR rather than treating archived PHI as lower-risk by default.
5. Formal retirement. Once extraction is validated and legal sign-off is documented, retire the legacy system’s licensing, hosting, and remaining interfaces on a scheduled date — not an indefinite “keep it around just in case” limbo that continues accruing licensing costs without a clear end point.
6. Periodic re-validation. Schedule recurring checks that the archive remains retrievable and legible as storage formats, archive vendors, and organizational staff change over the years the data must still be kept.

Treating decommissioning as a one-time IT project rather than an ongoing information-governance commitment is the single most common source of the “we can’t actually retrieve that record” problem years down the line.

Related reading

• EHR Optimization Strategies for the Post-Go-Live Era
• EHR Implementation Best Practices: A Field Guide

Frequently Asked Questions

Does HIPAA require medical records to be kept for six years?

No. The six-year rule applies to HIPAA compliance documentation — policies, risk assessments, training records — not clinical records. Medical record retention is governed primarily by state law, which HIPAA does not preempt, and retention periods vary by state and record type.

What’s the difference between active archiving and decommissioning?

Active archiving moves rarely used data out of a production system while that system stays live, mainly to improve performance. Decommissioning goes further: it retires the legacy system entirely once its data is migrated into a governed archive that becomes the new system of record.

Can a legacy EHR be fully shut down once data is archived?

Only after extraction is validated for completeness and clinical usability, legal and compliance sign off on the retention schedule, and any patients under legal hold are identified. Shutting down before that validation risks losing the ability to re-extract data if a gap is later discovered.

Who should be involved in planning a legacy EHR decommissioning?

Legal counsel, health information management leadership, compliance, clinical informatics, and IT should all be involved from the start. Treating decommissioning as a pure IT infrastructure task, without legal and HIM sign-off on retention and access governance, is a common source of later compliance and continuity problems.

How long must records for pediatric patients be retained?

Longer than typical adult retention periods in most states, often tied to the patient reaching the age of majority plus an additional statutory window — which can mean records for a patient treated in infancy must remain retrievable for two decades or more. Organizations should confirm the specific rule in every state where they operate.

This article is intended for general informational purposes for health IT professionals and does not constitute legal, compliance, or medical advice. Retention schedules and decommissioning plans should be confirmed with qualified legal counsel and health information management professionals for the specific states and record types involved.