The highest-risk moment in any healthcare IT transition is not always a cyberattack. It is the data migration itself. When a multi-location practice moves clinical records to a cloud-based electronic health record (EHR) system, the window between the old environment and the new one is where HIPAA violations quietly happen. A misconfigured access control, a business associate agreement (BAA) that does not cover a new vendor, or a transfer that routes through an unencrypted channel can each trigger a reportable breach before a single patient logs in to a new portal.
This guide walks through the legal and technical requirements that determine whether a cloud EHR migration is compliant from day one or a liability from the moment data moves. It is written for physicians, practice administrators, and operations leaders at multi-location practices who are planning or currently executing an EHR transition.
Why Cloud EHR Migrations Carry Disproportionate HIPAA Risk
Moving protected health information (PHI) from one system to another is not a routine IT task. Under the HIPAA Security Rule, covered entities are required to implement technical safeguards to guard against unauthorized access to PHI transmitted over electronic communications networks. During a migration, PHI is in transit, in temporary staging environments, and often handled by third-party vendors simultaneously. Each of those stages introduces a distinct compliance gap.
The Office for Civil Rights (OCR) at the U.S. Department of Health and Human Services has made clear that cloud service providers handling PHI on behalf of a covered entity are business associates under HIPAA. That classification carries specific legal obligations, and failure to formalize that relationship before data moves is one of the most common compliance failures OCR identifies in enforcement actions.
Migrations also introduce a category of risk that routine operations do not: the temporary coexistence of PHI in multiple environments at once. Until the legacy system is formally decommissioned, a practice is responsible for maintaining compliant access controls in both the old system and the new one.
The BAA Gap: The Most Common Compliance Failure in Cloud Migrations
The business associate agreement is the legal contract that defines how a vendor may use, access, store, or transmit PHI on behalf of a covered entity. Under HIPAA, a covered entity cannot lawfully disclose PHI to a business associate without a valid BAA in place. That requirement is absolute. There is no exception for data that is encrypted in transit, and there is no grace period during a migration window.
The gap most practices miss: a BAA must exist not just with the destination EHR vendor, but with every third-party service that touches PHI during the migration. That includes:
The migration services firm or managed IT provider executing the transfer
Any cloud storage or staging environment used during the process. Amazon Web Services, Microsoft Azure, and Google Cloud are all considered business associates when used to process or store PHI, regardless of whether they can access readable data.
Data mapping or transformation tools used to reformat or convert legacy records
Any intermediary platforms used to move data between environments
HHS guidance on cloud computing and HIPAA confirms that cloud service providers are business associates regardless of whether they can view PHI in readable form. Encryption does not eliminate the BAA obligation. It only satisfies the encryption technical safeguard requirement separately.
Before any data moves, every vendor in the migration chain must have a signed, current BAA on file.
What a Valid BAA Must Cover
Not all BAAs are equal. An agreement that omits critical provisions can leave a practice exposed even if the document technically exists. At minimum, a compliant BAA must specify:
The permitted uses and disclosures of PHI by the business associate, defined explicitly
Subcontractor requirements. Does the vendor engage downstream partners who will also access PHI? If so, those subcontractors must operate under their own BAAs with the same protections.
Breach notification timelines. Under the HIPAA Breach Notification Rule, business associates must notify covered entities of a breach without unreasonable delay and no later than 60 days after discovery. The BAA must reflect this obligation.
Requirements for the return or destruction of PHI at contract termination
The covered entity’s right to audit the business associate’s compliance
Practices should request written confirmation that the cloud EHR vendor’s BAA extends to all subprocessors. A vendor that relies on a cloud infrastructure provider lacking its own BAA coverage creates a break in the compliance chain, one that the covered entity is ultimately responsible for.
Data Handling Controls: The Technical Side of Compliance
Beyond the legal framework, the technical configuration of the migration must satisfy the HIPAA Security Rule’s implementation specifications. The following controls must be validated before data moves.
Encryption in transit and at rest
PHI must be encrypted during transfer and in any staging environment used during the migration. NIST Special Publication 800-111 provides guidance on storage encryption for end-user devices and systems. For data in transit, TLS 1.2 or higher is the current accepted standard. Any staging server that temporarily holds records during migration must meet the same encryption standard as the destination system.
Access controls
Role-based access controls (RBAC) must be defined and tested in the new system before migration begins. During a migration, it is common for IT teams to grant broad or temporary access to facilitate data transfers. Access that is not formally revoked after the migration creates a persistent audit trail problem and a security gap that may go undetected until a breach occurs.
Audit logging
The HIPAA Security Rule requires covered entities to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain PHI. The new EHR environment must have audit logging enabled and configured before records arrive. Enabling it after go-live leaves a gap in the activity record that cannot be reconstructed retroactively.
Data integrity verification
After transfer, a formal validation process must confirm that records were not altered, deleted, or corrupted during migration. HIPAA requires covered entities to protect PHI from improper alteration or destruction. A migration that moves records without validating integrity fails that requirement, even if no breach occurred and no patient was harmed.
The Multi-Location Problem
For practices operating across multiple sites, cloud EHR migrations carry compounding risk. Each location may have its own network infrastructure, legacy hardware configurations, active directory or identity management setup, local staff workflows, and patient population data with different volume and structural characteristics.
A migration that validates compliance at the primary site but skips a thorough review at satellite locations is still a breach waiting to happen. HIPAA does not grade coverage by site. A violation at any location within a covered entity is a violation for the entity as a whole, and OCR’s enforcement actions reflect that standard.
Multi-location practices should insist on a site-by-site readiness assessment before migration begins. A blanket evaluation that assumes all sites are operationally equivalent will miss the gaps that trigger violations.
Particular attention is warranted at locations that run older operating systems, rely on non-standard network configurations, or have limited local IT support. These are the sites where misconfigured access controls and unencrypted transfer paths are most likely to occur.
A Pre-Migration Compliance Checklist
Before any data moves, a HIPAA compliant EHR migration requires the following:
Signed BAAs with every vendor touching PHI during migration, including IT services providers, cloud platforms, and data conversion tools
Written confirmation that vendor BAAs extend to all subprocessors and downstream partners
Encryption protocols validated for data in transit and in any staging environments
Role-based access controls defined, tested, and restricted in the destination system
Audit logging enabled in the new environment before records are transferred
A data validation plan to verify record count, integrity, and completeness post-transfer
A breach notification protocol in place covering the migration period, including escalation contacts and timelines
A site-by-site readiness assessment for every location in the practice
Staff training on new system workflows completed before go-live, not scheduled for after
None of these steps are optional under HIPAA. Treating them as a post-launch checklist is the category of error that generates OCR enforcement actions and, in serious cases, civil monetary penalties.
Decommissioning the Legacy System
Compliance does not end when the last record transfers. The post-migration phase introduces its own risk. The legacy EHR system still contains PHI until it is formally decommissioned, and a practice that migrates to a new cloud platform but leaves the old system running without proper access controls now has PHI in two environments, both of which require full HIPAA coverage.
Decommissioning a legacy EHR system requires:
Formal data retention analysis. HIPAA defers to state law on medical record retention timelines, which typically range from 6 to 10 years depending on the state and the type of record. Not all records can be immediately destroyed.
Documented destruction or secure archiving of records that no longer need to be active in a live system
Termination or formal modification of any BAAs tied to the legacy system vendor
Verification that backup copies of legacy data are also properly secured or destroyed, not simply left on decommissioned servers or tape archives
Rushing decommissioning to cut costs is one of the more common ways practices inadvertently create PHI exposure after a migration is otherwise considered complete. An archived backup sitting on an unsecured server three months after go-live is a HIPAA problem.
Engage a HIPAA-Experienced IT Partner Before Migration Begins
A HIPAA compliant EHR migration is as much a legal and operational challenge as it is a technical one. Practices that treat it as a standard data transfer often discover compliance gaps after data has already moved, which is precisely the wrong time to find them. Techvera’s Healthcare IT practice is built specifically for multi-location medical and clinical organizations navigating transitions like this.
Our Compliance Readiness services help practices map the full vendor landscape before migration begins, identify BAA gaps across every party in the migration chain, and validate that both the legal agreements and technical controls are in place before any data moves. Our cybersecurity team conducts pre- and post-migration security assessments to confirm that access controls, audit logging, and encryption meet HIPAA requirements across every location in the practice, not just the primary site.
For practices approaching a cloud EHR transition, the right time to engage is before the migration plan is finalized, not after a compliance gap has already been identified. By the time a gap surfaces, data has moved.
Schedule a HIPAA Risk Assessment to have Techvera review your migration plan, validate your BAA coverage, and identify technical gaps before a single record moves.
About the Author
Team Techvera
Techvera Team
Articles written collaboratively by the Techvera team, combining expertise across cybersecurity, managed services, and digital transformation.