What to Ask Before Migrating PHI Systems to the Cloud

import CTA from ’../../components/CTA.astro’;

What should you ask before migrating PHI systems to the cloud?

Before migrating PHI systems to the cloud, ask who will sign the business associate agreement, which services are actually in scope for regulated workloads, how identity and privileged access will be controlled, where audit logs will live, how encryption and key management will work, what recovery commitments apply, and who owns vendor escalation during an incident.¹²³⁴

That sounds like a long list because it is a long list. A PHI migration is rarely just a hosting project. It changes where protected data lives, how staff authenticate, how interfaces connect, how backups are handled, and which team becomes responsible when something breaks at 2:00 AM. If those questions are answered only with general reassurances like “the cloud provider is HIPAA-ready,” the organization is probably still too early in the decision process.

We think healthcare teams get the best outcomes when they treat migration planning as an operating-model review instead of an infrastructure refresh. The cloud can absolutely improve resilience, scale, and recoverability. But it also makes weak ownership much more visible. That is why the questions matter before the move, not after the first outage or audit request.

If your team is already tightening healthcare IT governance, this topic also pairs naturally with our guidance on how to assess whether an MSP SLA covers critical clinical workflows, HIPAA audit log requirements in Microsoft 365, and the broader HIPAA-compliant IT services guide.

Why does a PHI cloud migration need more diligence than a normal infrastructure project?

A PHI migration carries a different level of operational and regulatory consequence because the environment supports protected health information, patient-facing workflows, and incident-response obligations that cannot be left vague. HIPAA does not magically disappear when a workload moves to a cloud platform. The responsibility model changes, but the accountability stays with the covered entity and its business associates.¹³⁴

That is why buyers should slow down whenever a project is framed as “just lifting the server into the cloud.” Even if the application itself barely changes, the surrounding controls usually do. Authentication may move to a different identity provider. Backups may shift to snapshots or platform services. Logging may land in a different console. Third-party integrations may cross new trust boundaries. Recovery assumptions may improve in theory while getting fuzzier in practice.

We usually recommend asking one blunt question early: what operational problem are we solving by moving this PHI system? If the answer is only cost, that is not enough. Better reasons include resilience, easier disaster recovery, consolidation, improved security controls, cleaner vendor accountability, or support for a larger modernization roadmap. Without that clarity, teams tend to inherit cloud complexity without getting real risk reduction in return.

Will the vendor sign a BAA, and what exactly does it cover?

The first practical question is whether every relevant provider in the chain will execute a Business Associate Agreement where required, and whether the BAA actually matches the services and workflows you plan to use.¹³

That means asking:

• Which provider is the business associate for this workload?
• Which services are covered under the provider’s HIPAA program or BAA scope?
• Are backup, analytics, logging, messaging, AI, or developer tools included or excluded?
• Does the BAA cover the exact tenant, subscription, project, or product family being proposed?
• Which subcontractors or downstream services are involved?

Cloud platforms often support HIPAA workloads, but support is not the same thing as “every service is automatically in bounds.” Microsoft notes that covered entities must enter into agreements with business associates, and cloud providers become business associates when they create, receive, maintain, or transmit PHI on behalf of the customer.¹ Google makes a similar point: HIPAA compliance is shared, and customers are still responsible for evaluating how their own use of services aligns with HIPAA obligations.⁴

If your migration plan depends on a service that is not included in the platform’s healthcare compliance scope, that is not a minor footnote. That is a stop-and-fix item.

What is the shared responsibility model for this specific PHI system?

One of the most important questions is also one of the most skipped: which security and operations tasks stay with us after the move? The answer changes depending on whether the workload runs as SaaS, PaaS, or IaaS.²

Microsoft’s cloud guidance is blunt here: the provider handles some layers of the stack, but customers still own major responsibilities such as identity, endpoint posture, data governance, application configuration, and many access-control decisions.² In healthcare migrations, that means teams should ask for a written responsibility map covering:

• identity and MFA ownership
• privileged access workflows
• operating-system patching or platform patching
• application updates
• certificate management
• network segmentation
• vulnerability remediation
• logging retention and review
• backup monitoring and restore testing
• security incident triage and escalation

We prefer responsibility tables over verbal explanations. If the migration team cannot show who owns each control after cutover, somebody important is probably assuming the other party has it.

How will identity, privileged access, and vendor access be controlled?

For most healthcare organizations, identity is where cloud migration risk becomes real. The question is not only whether users can log in. It is whether the organization can prove who had access, when they had it, and how elevated access is granted, reviewed, and removed.

Ask questions like these:

• Will the PHI system integrate with the existing identity platform or create a parallel login pattern?
• Is MFA mandatory for all remote, administrative, and privileged access?
• How are service accounts handled?
• How is vendor access approved, monitored, and revoked?
• Are break-glass accounts documented and tested?
• How often are privileged roles reviewed?

This is especially important when the migration introduces new cloud admins, third-party engineers, or managed-service access paths. A healthcare team might successfully move the workload and still weaken control if access sprawl grows faster than governance. We generally want the migration plan to reduce identity ambiguity, not multiply it.

Where will audit logs and compliance evidence come from?

A PHI cloud migration should make auditability better, not murkier. Before migration, ask where system logs, access logs, admin actions, configuration changes, and security alerts will be captured, how long they will be retained, and who can actually retrieve them during an investigation.¹⁴

The practical questions usually include:

• Which logs are native to the application versus the cloud platform?
• Are sign-in, admin, API, and data-access logs all available?
• How long is retention by default?
• Is extended retention extra?
• Who reviews the logs and on what cadence?
• Can the organization export evidence quickly for auditors, legal review, or incident response?

We have seen teams assume that “cloud logging” automatically means “audit-ready logging.” It does not. Sometimes the logs exist but are too short-lived. Sometimes they are in separate consoles. Sometimes they require an upgraded license. Sometimes nobody is assigned to review them. For regulated healthcare workloads, those are material design questions, not cleanup tasks for later.

How will encryption, key management, and data flow be handled?

Encryption questions should move beyond a checkbox. AWS and other major providers describe HIPAA support around protecting the confidentiality, integrity, and availability of PHI with administrative, physical, and technical controls, but the customer still needs to understand how its own workload is configured and operated.³⁴

Ask:

• Is PHI encrypted in transit and at rest by default?
• Are customer-managed keys needed or just provider-managed keys?
• Where do exports, interfaces, and temporary files land?
• Do integration points move PHI into other systems outside the migration scope?
• Are mobile or remote-access workflows changing?
• What data leaves the primary platform for backup, analytics, or support?

This is where “cloud-ready” architectures often reveal ugly surprises. A well-secured primary application can still feed reports to unsecured storage, transmit files through weak interfaces, or leave admin exports scattered across unmanaged locations. Migration planning should trace the full data flow, not just the main application screen.

What are the backup, recovery, and downtime expectations after migration?

Healthcare teams should ask how backup works in the new environment, who monitors it, how often restores are tested, what the expected recovery time is, and how downtime communication changes after the move.²³

We usually push teams to clarify:

• backup scope for databases, file stores, and configurations
• backup frequency and retention
• point-in-time recovery capabilities
• documented recovery time objective and recovery point objective
• restore-test cadence
• vendor coordination during a failed recovery
• downtime procedures if the hosted system or an identity dependency fails

A migration can improve resilience dramatically, but only if the organization translates platform capability into tested process. Snapshotting is not the same thing as business continuity. Cross-region replication is not the same thing as a validated application recovery plan. And a vendor saying “the service is highly available” is not the same thing as your clinicians being able to keep working.

How will integrations, interfaces, and dependent workflows be protected?

PHI systems almost never stand alone. They touch identity platforms, imaging systems, fax workflows, SFTP transfers, claims systems, M365 services, endpoint agents, and third-party support channels. A responsible migration review should ask what depends on the workload and what the workload depends on.

Good pre-migration questions include:

• Which integrations carry PHI or user context?
• Which interfaces will need reconfiguration after the move?
• Which vendors must validate connectivity?
• What happens if one dependency lags behind cutover?
• How will testing prove the end-to-end workflow, not just server reachability?

We like to distinguish application up from workflow usable. In healthcare, the second question matters more. If the core system is online but clinicians cannot authenticate, documents cannot route, or scanned records do not attach properly, the migration is not successful in any meaningful way.

Who owns incident response, vendor escalation, and change control after cutover?

A cloud migration often increases the number of parties involved in incident response: internal IT, the application vendor, the cloud provider, the MSP, identity administrators, security teams, and integration partners. That is exactly why ownership must be clarified before the move.

Ask the team to define:

• who declares a high-severity event
• who opens vendor tickets
• who communicates with leadership and affected departments
• who approves emergency changes
• who preserves logs and evidence
• who decides whether an event is a reportable security incident
• who owns the service review after resolution

This is one reason we usually recommend scenario-based tabletop questions before approval. Walk through an identity outage, a failed database restore, a suspicious-access event, and a partial application slowdown. If the room cannot answer who does what next, the migration plan is not ready.

A practical question list healthcare teams can use before approving migration

Before approving the move, we recommend getting direct written answers to at least these questions:

1. Which providers will sign BAAs, and which exact services are in scope?
2. What does the shared responsibility model look like for this workload?
3. How will identity, MFA, privileged access, and vendor access be governed?
4. Where will audit logs live, how long will they be kept, and who reviews them?
5. How is PHI encrypted in transit, at rest, and across integrations?
6. What is the tested backup and recovery model after migration?
7. Which dependent systems and vendors must be validated before go-live?
8. Who owns incident response, escalation, and downtime communication?
9. What compliance evidence will be easier to produce after the move?
10. What specific business or clinical risks are we reducing by migrating now?

If those answers are vague, leadership should not confuse momentum with readiness.

Frequently asked questions

Is a cloud provider being HIPAA-capable enough by itself?

No. A provider supporting HIPAA workloads is helpful, but it does not remove the healthcare organization’s responsibility to configure, govern, and monitor the environment correctly.¹²⁴

What is the most important question before moving a PHI system?

Usually it is some version of: who owns what after cutover? If the team cannot clearly map responsibility for access, logging, backup, incident response, and vendor coordination, the migration risk is still too high.

Should backup and downtime planning be reviewed before migration approval?

Yes. Recovery and downtime expectations should be defined before migration because platform resiliency features do not automatically equal tested operational recovery.

Why do PHI migrations fail even when the technology works?

Because the weak point is often not the server or platform. It is unclear ownership around integrations, identity, logging, escalation, and clinical workflow validation.

Sources

• Microsoft Learn: HIPAA & HITECH Act compliance offering
• Microsoft Learn: Shared responsibility in the cloud
• AWS: HIPAA Compliance
• Google Cloud: HIPAA Compliance on Google Cloud

Footnotes

1. Microsoft Learn: HIPAA & HITECH Act compliance offering ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Microsoft Learn: Shared responsibility in the cloud ↩ ↩² ↩³ ↩⁴ ↩⁵

3. AWS: HIPAA Compliance ↩ ↩² ↩³ ↩⁴ ↩⁵

4. Google Cloud: HIPAA Compliance on Google Cloud ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶