Buying new software gets all the attention. Retiring the old software gets almost none, which is why so many practices are still paying maintenance on a billing system they replaced four years ago, or keeping a dusty server in a closet because nobody is sure what is on it. Decommissioning done well frees budget, shrinks your security footprint, and satisfies retention obligations. Done poorly, it strands records you are legally required to produce or leaves patient data on a drive that ends up at a recycler.
Why old systems never die
Legacy systems persist for predictable reasons. Migration projects typically move only active patients or a limited lookback window, so older charts stay behind. Historical billing data is rarely migrated at all because the new system's data model does not match. Staff want the old system available "just in case." And the vendor contract auto-renews while everyone is focused on the go-live. Each reason is legitimate on its own; together they produce indefinite limbo. The fix is to treat decommissioning as a project with an owner, a scope, and an end date, planned at the same time as the new implementation rather than after it.
Know what you must keep
Before deciding how to preserve data, establish what must be preserved and for how long. Several obligations overlap:
- State medical-record retention laws set minimum periods for clinical records, often longer for minors and typically measured from the last date of service or from the patient reaching the age of majority.
- HIPAA documentation retention requires policies, procedures, and certain compliance documentation to be retained for six years. HIPAA itself does not set a retention period for the medical record; state law does.
- Payer and federal program rules impose their own retention on claims and supporting documentation, commonly seven to ten years for federal programs.
- Litigation holds override everything. If any record is subject to a hold, it cannot be disposed of regardless of schedule.
Write the resulting retention matrix down. It is the specification for the archive, and it also tells you what you may eventually destroy.
Three ways to preserve the data
Full migration. All records move into the new system. This is cleanest for clinicians but expensive and often technically incomplete: scanned documents, audit trails, and billing history frequently do not survive the trip intact. Verify that the migrated record is a legally sufficient copy, including metadata such as who documented what and when.
Read-only archive in the legacy system. The old application stays running with a reduced license, no new data entry, and a small number of user accounts. This preserves fidelity perfectly but keeps a server, an operating system, and a vendor relationship alive, all of which must be patched, backed up, and included in your security risk analysis for as long as they exist.
Archival export to a neutral format. Records are exported to PDF, structured documents, or a dedicated archiving platform, indexed by patient, and the legacy application is shut down. This is usually the best long-term answer for data past its active life. The risks are export gaps and loss of structure, so validate exports against a sample of source records before the source is gone.
Whichever path you choose, insist on a reconciliation report: a count of patients, encounters, documents, and claims in the source, matched against the destination, with every discrepancy explained. Do not turn off the source until that report is signed.
Exiting the vendor contract
Read the termination and data-return clauses before giving notice. Look for the notice period and the auto-renewal date, the format and cost of the final data export, how long the vendor will retain your data after termination and how it will be destroyed, and whether a business associate agreement survives termination to cover that retention window. Request a written certificate of destruction when the vendor purges your data. If the vendor hosted the system, confirm in writing that backups and replicas are included in the purge, not just the production copy.
The decommission runbook
- Freeze new data entry in the legacy system on a published date and communicate it to all users.
- Complete and validate the final export or migration; sign the reconciliation report.
- Disable all user accounts except a small archive-access group with logged, role-based access.
- Remove integrations: interfaces, scheduled jobs, clearinghouse connections, remote-access paths, and firewall rules that existed only for the legacy system.
- Update your asset inventory, data-flow diagrams, and security risk analysis to reflect the change.
- Give contractual notice and obtain the vendor's destruction certificate.
- Take final full backups of anything you are retaining locally, verify they restore, and store them per your retention matrix.
- Power down and sanitize hardware only after the retention copy is verified.
Hardware and media disposal
The HIPAA Security Rule requires policies for the final disposition of electronic PHI and the media it lives on, and for removing ePHI before media are reused. NIST's media sanitization guidance describes the accepted methods: clearing, purging, or destroying, chosen based on the media type and how sensitive the data is. For drives that held clinical or billing data, purge or physical destruction is the norm, and you should obtain a certificate of sanitization from whoever performs it. Do not forget the places data hides outside the main server: workstation caches, local database copies, USB backups, printers and multifunction devices with internal storage, and the old backup tapes in the fire safe.
A decommissioned system should leave three artifacts behind: a verified archive that satisfies the retention matrix, a signed reconciliation report, and destruction certificates for both the vendor's copy and your own hardware. If you have those, the project is finished. If you do not, it is not.
Common questions
How long must a practice keep records from a retired EHR or billing system?
Retention is driven by state medical-record laws, payer and federal program rules, and HIPAA's six-year requirement for compliance documentation. The longest applicable period controls, and litigation holds override any schedule. Build a written retention matrix before deciding how to archive.
Is it acceptable to keep the old system running in read-only mode?
Yes, and it preserves data fidelity well, but the system remains an asset that must be patched, backed up, access-controlled, and included in your security risk analysis for as long as it runs. Many practices use read-only mode as a bridge and then export to a neutral archive.
What should the vendor provide when the contract ends?
A complete data export in a usable format, written confirmation of how long they will retain your data afterward, and a certificate of destruction once it is purged, including backups and replicas. Confirm the business associate agreement covers the post-termination retention window.
How should old servers and drives be disposed of?
Follow the Security Rule's device and media controls and NIST media sanitization guidance: purge or physically destroy media that held ePHI, obtain a certificate of sanitization, and remember hidden copies on workstations, printers, USB drives, and backup tapes.