What Should a Legacy EHR Sunset Plan Include? Read-Only Access, Retention, and Liability After Migration

TL;DR

• Most practices should retain read-only access to a legacy EHR for at least 2 to 3 years post go-live, though pediatrics, behavioral health, and malpractice-heavy specialties often need longer.
• Medical record retention is governed primarily by state law, not HIPAA, and ranges from 5 years to "until age of majority plus a set number of years" for minors. HIPAA itself only requires 6 years of retention for HIPAA-related documentation (policies, BAAs, authorizations), not clinical records themselves.
• The covered entity (the practice) remains legally liable for patient record requests and disclosures even after migration, regardless of which vendor is hosting the old data. Contracts with the outgoing vendor should spell out data custody, breach obligations, and support timelines in writing before the migration project closes.
• A sunset plan is not just "turn off the old system." It is a documented decommissioning process covering data validation, read-only access duration, user deprovisioning, retention scheduling, legal holds, and a named accountable owner.
• The biggest operational risk is not losing data. It is losing the ability to retrieve it correctly when a subpoena, malpractice claim, or patient records request arrives 18 months after nobody remembers the legacy system's login process.

What Should a Legacy EHR Sunset Plan Include?

A legacy EHR sunset plan should include a validated data migration audit, a defined read-only access window, a documented retention schedule aligned to state law, a records request procedure that spans both systems, and clear contractual liability language with the outgoing vendor.

Most sunset plans fail not because of any single missing step but because they are treated as an afterthought to the migration project rather than a parallel workstream with its own owner, budget, and timeline. In practice, a sunset plan needs six components:

1. Data migration validation report. Before anyone talks about decommissioning, someone needs to confirm what actually moved. This means reconciling patient counts, chart note counts, lab result counts, and document counts between old and new systems, not just spot-checking a handful of charts. Discrepancies here become the justification for how long read-only access needs to stay live.
2. Read-only access period with a defined end date. Not "we'll keep it around for a while." A specific date, tied to a specific business reason (state retention minimums, litigation exposure, payer audit windows), documented in writing and revisited quarterly.
3. User access deprovisioning schedule. Legacy systems accumulate zombie accounts. A sunset plan should specify who retains access during the read-only period (usually HIM staff, compliance, and a designated clinical lead) and when everyone else is cut off, typically at go-live plus 30 to 90 days.
4. Retention and destruction schedule tied to actual law. Not a guess. A written schedule referencing the specific state statute or regulation, the specific record type, and the calculated destruction or archive date.
5. A records request procedure that spans both systems. Staff fielding a records request 14 months post-migration need a clear answer to "where do I look" without escalating to IT every time.
6. Contractual liability and support terms with the outgoing vendor, executed before the migration is declared complete, not negotiated retroactively after the vendor's support team has moved on to other accounts.

How Long Should a Clinic Keep Read-Only Access to a Legacy EHR After Migration?

Most outpatient practices should plan on 24 to 36 months of read-only legacy access, with longer windows for pediatric, obstetric, or high-litigation-risk specialties.

There is no single federal rule dictating this number, which is exactly why so many practices get it wrong in both directions. Some shut off legacy access within 90 days to save on licensing costs, then get burned when a patient records request or malpractice discovery demand arrives and nobody can produce the original documentation in its native format. Others keep every legacy system running indefinitely "just in case," paying maintenance fees for systems nobody has logged into in two years while quietly increasing their attack surface with an unpatched, rarely monitored application.

A more defensible approach ties the read-only window to actual risk exposure:

• General adult primary care and endocrinology records: 24 to 36 months of read-only access covers most malpractice statute of limitations windows (commonly 2 to 3 years from the incident, though tolling rules vary by state) and most payer audit lookback periods.
• Pediatric records: Malpractice statutes of limitations for minors often do not start running until the age of majority, meaning a chart for a newborn could remain legally relevant for close to two decades. Practices with pediatric or adolescent panels should plan for extended archival access, not necessarily a live read-only login, but a validated static export.
• OB and high-risk specialties: Similar logic applies. If your specialty touches long-tail liability exposure, the sunset plan should default toward archive-and-preserve rather than delete-on-schedule.
• Behavioral health records: Some states impose stricter confidentiality and retention rules for psychiatric or substance use records, sometimes requiring separate handling entirely.

The honest operational tradeoff here is cost versus risk. Keeping a legacy EHR live and licensed for three years is not free, vendors often charge maintenance fees disproportionate to actual usage once a practice is no longer their active customer. The alternative, converting to a static archive (validated PDF exports, CCDs, or a read-only data warehouse) after an initial live read-only period of 6 to 12 months, is usually cheaper and still legally defensible if done correctly.

What Are the Medical Record Retention Requirements After Switching EHR Systems?

Medical record retention requirements do not change because you switched EHR systems. The same state law that governed retention in the old system still applies to every record now sitting in the new one or archived from the old one.

This is a point of genuine confusion for IT admins managing a migration: switching systems does not reset the retention clock, and it does not create a new, shorter obligation. The record's retention requirement is tied to the record's creation date and content type, not to which software currently stores it.

A few grounding facts:

• HIPAA does not set a clinical record retention period. The HIPAA Privacy Rule requires covered entities to retain documentation of HIPAA-related policies, procedures, and authorizations for 6 years, but it does not dictate how long you must keep the clinical chart itself. That's a common misconception that leads practices to assume "6 years" is a safe universal number. It often is not long enough.
• State law is the primary driver, and it varies significantly. Some states specify a flat number of years (commonly 5 to 10 years for adult records). Many specify a different, longer period for minors, often extending until the patient reaches the age of majority plus an additional set number of years.
• Medicare and Medicaid have their own retention expectations tied to audit and cost-report timelines, generally in the range of several years from the date of service, and these can run independently of state medical record law.
• Malpractice insurers frequently recommend retention periods longer than the legal minimum, because their own claims exposure calculus is different from a straight compliance read. It's worth pulling your malpractice carrier's recommended retention guidance during the sunset planning process, not after a claim arrives.

Because these requirements vary by state and record type, a sunset plan should never rely on a single retention number applied uniformly. The retention schedule should be built as a table: record type, applicable law or guideline, calculated retention date, and current storage location (live legacy system, static archive, or new EHR).

Who Is Liable for Old Patient Records After an EHR Migration Is Complete?

The covered entity, meaning the practice itself, remains liable for old patient records after migration, and that liability does not transfer to the new EHR vendor or automatically terminate with the old vendor's contract.

This is the piece of the sunset plan most frequently mishandled, because IT teams sometimes assume that once data has moved to Thyra or any new EHR, responsibility for the old records moves with it, or that the outgoing vendor absorbs liability once the contract ends. Neither assumption is safe without explicit contract language.

Here's how liability actually breaks down in most scenarios:

• The practice (covered entity) is always liable for responding to patient records requests, subpoenas, and regulatory inquiries about care documented in the legacy system, regardless of where that data physically lives now. HIPAA liability for the underlying PHI does not evaporate because the software changed.
• The outgoing vendor is typically a business associate, and business associate agreements (BAAs) generally survive termination of the underlying services contract for purposes of breach notification and safeguarding obligations, unless the BAA explicitly says otherwise. If your outgoing vendor's BAA has an expiration clause tied to contract termination rather than data destruction, that's a gap worth closing before you sign the decommission paperwork.
• Data destruction certification matters. If the legacy vendor destroys data as part of decommissioning, get written certification of destruction, including method and date. Without it, you have no defensible answer if a records request arrives and you can no longer produce the data because the vendor deleted it without documentation.
• New system vendors are not automatically liable for legacy data gaps. If a patient's old allergy list didn't migrate correctly and it later informs a clinical decision, most vendor contracts (Thyra's included, as with essentially every EHR vendor) don't accept liability for migration accuracy without an explicit data migration services agreement covering validation responsibility. This is why the validation step in the sunset plan matters more than almost anything else, it's your best evidence that the migration was executed with reasonable diligence.
• Support obligations after contract termination should be negotiated explicitly, ideally before the migration project is scoped. Vendors are far more cooperative about read-only access windows, export formats, and support SLAs when it's part of the original contract negotiation than when you're calling six months after your Master Services Agreement expired.

The practical takeaway for IT admins: get the outgoing vendor's data custody, BAA survival terms, and post-termination support commitments in writing during the migration contract negotiation, not after go-live. Once the vendor relationship has cooled and their implementation team has moved to other accounts, negotiating leverage disappears.

What Happens to Data That Wasn't Migrated?

Data that wasn't migrated doesn't stop being a legal record just because it stayed behind, and it needs its own line item in the sunset plan rather than being treated as acceptable loss.

No migration moves everything cleanly. Free-text notes in nonstandard formats, scanned documents buried in unusual file structures, old fax logs, and legacy lab interface data that predates the migration's data mapping scope are common casualties. The sunset plan should explicitly document what categories of data were excluded from migration and why, along with where that data will live and for how long. "We didn't migrate it" is not the same as "it no longer needs to be retained." If a state audit or malpractice discovery request touches a record type that wasn't migrated, the practice still needs to produce it, which means the legacy system (or a validated archive of it) needs to remain accessible for the full retention period regardless of migration completeness.

How Should You Budget and Contract for Legacy System Access?

Budget for legacy system access as a distinct, time-bound line item with a hard end date, not as an open-ended maintenance cost folded into general IT overhead.

Practices frequently underestimate the cost of keeping a legacy EHR minimally operational for read-only access: hosting fees, a reduced but nonzero support contract, security patching obligations, and staff time to manage access requests all add up. Negotiate a read-only support tier with the outgoing vendor at the time of migration, ideally at a meaningfully reduced rate compared to the full active license, since you're no longer using scheduling, billing, or e-prescribing functionality. Vendors are generally willing to offer this, but only if it's negotiated as part of the exit terms rather than requested as a favor after the relationship has ended.

None of these models is universally correct. A live read-only system preserves the most clinical fidelity, including original formatting, embedded images, and click-through history, but it's the most expensive to maintain and carries the most residual security risk if patching lapses. A static archive is cheaper and lower-risk from a security standpoint but can lose some clinical context if the export process wasn't validated carefully before decommissioning. The right answer is usually a phased approach: live read-only for the first 12 to 24 months while records requests are most frequent, transitioning to a validated static archive for the remainder of the retention period.

Frequently Asked Questions

Does HIPAA require a specific EHR data retention period?

No. HIPAA requires 6 years of retention for HIPAA-related documentation such as policies, BAAs, and authorizations, but it does not set a retention period for the clinical record itself. Actual medical record retention is governed by state law, which varies and is often longer than 6 years, particularly for minors.

Can we just export everything to PDF and shut down the legacy EHR immediately?

You can, but it carries risk if the export wasn't independently validated against the source system first. PDF exports can lose structured data, embedded images, or interactive elements like flowsheets, and if a records request later reveals gaps, the practice bears the liability. A validated export, confirmed against a sample audit of the original system, is safer than an unvalidated bulk export followed by immediate shutdown.

Who pays for maintaining read-only access to the legacy EHR?

The practice does, typically through a reduced-rate support agreement negotiated with the outgoing vendor. This should be scoped and priced during the migration contract negotiation, not requested informally afterward when the vendor has less incentive to offer favorable terms.

What happens if the legacy vendor goes out of business before the retention period ends?

This is exactly why data escrow or a validated local/warehouse export matters. If retention depends entirely on the outgoing vendor staying in business and hosting your data, you have a single point of failure. Practices should have their own validated copy of critical legacy data independent of the outgoing vendor's continued operation.

Should the sunset plan be part of the EHR migration contract with the new vendor?

The sunset plan itself involves the outgoing vendor, not the new one, but the new vendor's migration services agreement should clearly define what was migrated, how it was validated, and what wasn't included in scope. That documentation becomes evidence supporting your legacy retention decisions.

About the Author

This post was prepared by the clinical and product team at Thyra, an EHR built for endocrinology and primary care by Dr. Jean Jacques Nya Ngatchou. Thyra supports practices through EHR transitions, including running alongside legacy systems before go-live, and works with implementation teams to plan data validation and legacy decommissioning as part of every migration engagement.

References

• U.S. Department of Health and Human Services, HIPAA Privacy Rule, documentation retention requirements (45 CFR 164.530).
• State medical board and state health department medical record retention statutes (retention periods vary by state; consult your specific state's medical practice act or health department guidance).
• Centers for Medicare & Medicaid Services (CMS), record retention requirements for Medicare providers.
• Industry guidance from health information management professional organizations on best practices for retention and destruction of health information (consult your organization's HIM or compliance staff for current guidance).
• HHS Office for Civil Rights, guidance on Business Associate Agreements and post-termination obligations.