Healthcare IT publications cover EHR migrations as operational stories: the change in clinician workflow, the training burden, the productivity dip in the first 90 days. The security dimension of these projects gets less coverage, and the regulatory dimension less still. Healthcare IT News reported this month on South Central Regional Medical Center's consolidation of five clinical sites onto a single Epic instance — the kind of transition that happens regularly across the U.S. health system and rarely makes the breach-news pages. The reason it rarely makes the breach-news pages is partly that the security failures during these windows tend to surface eighteen months later, attributed to other causes.
The structural problem
EHR migrations create a defined interval — typically six to eighteen months — during which the practice's data is moving across systems, access controls are being reconfigured, and the records of who can see what are in flux. That interval is the security event. It has features that make it especially hard to defend.
Two systems are partially live simultaneously. The legacy EHR is being read while the new one is being written. Access controls in the legacy system may relax during the transition to allow data extraction. Access controls in the new system may not yet be fully tuned, with default roles being broader than the eventual role design. The combined access surface is larger than either steady-state.
Vendor staff have temporary elevated access. Migration consultants, integration engineers, and the EHR vendor's professional services staff need substantial access to both systems during the cutover. Business associate agreements typically cover this, but the practice often doesn't have visibility into what the vendor's staff actually accessed during the transition window. If a breach surfaces later and the practice can't account for who saw what during migration, the regulator's response is rarely favorable.
The audit trail breaks at the system boundary. Audit logs in the legacy system end at the migration. Audit logs in the new system start at go-live. The interval covering the actual data movement — the period when most data was in transit, in temporary databases, in test environments, on consultant laptops — often has no continuous audit record. Investigators of a later breach trying to reconstruct what happened during the migration window encounter a gap.
What's typically missing from the project plan
The standard EHR migration project plan covers training, workflow redesign, integration testing, and go-live readiness. The security and compliance work is usually a sub-bullet under "IT readiness." The activities that matter most often aren't enumerated.
Defined access scope for the migration team. Each consultant, integration engineer, and vendor staff member should have an explicit scope of access — which databases, which patient cohorts, which functions. Standing accounts with broad permissions are the easy choice and the wrong one.
Audit logging continuity through the transition. Both systems should retain logs through the entire migration window, with extended retention beyond steady-state. The temporary databases used for ETL should themselves have access logs that can be reconstructed if needed.
Pre-migration access review. A clean baseline of who has access to what, in the legacy system, before the migration begins. Without this, post-migration audit can't distinguish "this user always had access" from "this user gained access during migration."
Post-migration access reduction sweep. After cutover, accounts that had elevated permissions during migration should drop back to steady-state scope. Practices that skip this step routinely find a year later that consultants and contractors retained broader access than they should have.
Documented data destruction at migration partners. When the consultants and integration engineers complete their work, the practice's data on their systems should be destroyed under documented terms. The BAA specifies the requirement; the practice rarely verifies it.
Why this matters now
The 2026 HIPAA Security Rule update, expected to be finalized in May, is widely understood to include more explicit requirements around access management, audit logging, and vendor oversight. Practices in the middle of an EHR migration when the rule finalizes will find themselves rebuilding compliance documentation against a moving target.
For independent practices considering or starting a migration this year, the practical implication is to treat the migration window itself as a project deliverable in the compliance program — with named owners, dated artifacts, and a defined verification step. The IT side of the migration will get the attention it deserves regardless. The compliance side will get attention only if someone makes it a milestone.
The South Central Regional case will probably proceed without incident, like most migrations do. But "most migrations" is a survivorship-biased frame. The migrations that produce breaches don't surface until eighteen months later, and by then the project plan has been archived, the consultants have left, and the audit trail is partial. The compliance work that's done during the migration window is the work that stands up later. The compliance work that gets deferred to "after we go live" is the work that turns into a finding.
Read the original at Healthcare IT News →