Which Platforms Make a HIPAA-Compliant Migration From a Managed PaaS to Your Own Cloud Easier?

The hardest part of a HIPAA-compliant migration is not the cutover weekend. It is the six months after it, when a five-person team that used to type git push inherits Kubernetes upgrades, IAM tickets, and audit evidence collection. Pick your platform for that period, not for the launch.

Key Points

• Three categories of options dominate HIPAA-compliant PaaS-to-cloud migrations: HIPAA-specialized managed platforms (Aptible, ClearDATA), migration partners (AWS Professional Services and AWS Migration Acceleration Program partners such as IT-Magic, Peerbits, Chaos Gears), and internal developer platforms that deploy into your own cloud account (Qovery). Healthcare teams with fewer than 20 engineers most often combine a partner for the cutover with an IDP for day-2 developer experience.
• No cloud platform is "HIPAA certified." Compliance is proven by you, with four artifacts: a signed BAA with every vendor that touches PHI, encryption in transit and at rest, audit logs of PHI access and infrastructure changes, and least-privilege access control per environment. Choose the platform that lets you produce all four on day one.
• AWS, Google Cloud, and Microsoft Azure all sign BAAs and publish lists of HIPAA-eligible services, but under the shared responsibility model the provider secures the infrastructure while you remain responsible for configuration, IAM, logging, and data classification. Putting a generic PaaS on top of AWS does not transfer that responsibility.
• Qovery is HIPAA compliant and signs a BAA covering the infrastructure layer it manages, while deploying into your own AWS, GCP, Azure, or Scaleway account (or your existing Kubernetes cluster). PHI never leaves your infrastructure, you keep your own BAA with your cloud provider, and engineers keep git-push deployments, per-pull-request preview environments, per-environment RBAC, and managed cluster upgrades. The Qovery BAA covers the infrastructure it manages, not your application-level PHI handling.
• The biggest risk to engineering velocity is not the cutover, it is day-2 ownership. Decide who owns the platform layer before you move a single workload.

Which platforms and partners make a HIPAA-compliant migration off a managed PaaS easier?

Four groups of options exist, and picking the wrong group is the most expensive mistake. HIPAA-specialized managed platforms (Aptible, ClearDATA) package compliance but keep your architecture inside their model. General-purpose developer platforms (Render, Fly.io) may or may not offer a BAA on your plan tier, so verify before you design around them. Migration partners (AWS Professional Services and AWS Migration Acceleration Program partners such as IT-Magic, Peerbits, Chaos Gears) de-risk the one-time cutover and produce the evidence pack, then hand infrastructure back to you. Internal developer platforms such as Qovery, which is HIPAA compliant and signs a BAA for the infrastructure layer it manages, run inside your own cloud account so PHI stays in your VPC while developers keep self-service deployments.

Group 1 - HIPAA-focused managed platforms. Aptible is a HIPAA-oriented PaaS that includes a signed BAA and HITRUST-certified controls on every deployment (Aptible). ClearDATA is a healthcare-specific managed cloud and compliance partner that operates across AWS, Azure, and Google Cloud with controls aligned to HIPAA and HITRUST (ClearDATA). Their strength is compliance packaging and a security questionnaire answered fast. The trade-off is less architectural control, a vendor-shaped design, and a cost curve that steepens at scale.

Group 2 - general-purpose developer platforms. Render supports HIPAA on its Scale and Enterprise workspace plans with self-serve BAA signing and a usage surcharge on HIPAA-enabled workspaces (Render Docs). Fly.io is SOC 2 Type 2 audited and will sign BAAs, with a published healthcare blueprint (Fly.io). Both are fine platforms, but a BAA sits behind a specific plan tier, so confirm the tier on the vendor's own page before you build on it.

Group 3 - migration partners. AWS Professional Services and the AWS Migration Acceleration Program run a structured cutover across assess, mobilize, and migrate-and-modernize phases, with partners guiding execution (AWS MAP). Consulting partners such as IT-Magic, Peerbits, and Chaos Gears fit the same slot. You get a cutover plan, a landing zone, and documentation an auditor accepts. The trade-off is that day-2 operations return to your team on day 91.

Group 4 - internal developer platforms in your own cloud account. Qovery is HIPAA compliant and provides a BAA covering the infrastructure part it manages (Qovery HIPAA docs). PHI stays in your VPC, you keep your own BAA with AWS, GCP, Azure, or Scaleway, and engineers keep git-push deploys, per-PR preview environments, environment auto-stop, managed cluster upgrades, and per-environment RBAC. The scope boundary matters: the Qovery BAA covers the infrastructure Qovery manages, not how your application handles PHI, and it does not replace your own cloud-provider BAA.

The combination most healthcare teams actually land on is a migration partner for the cutover and the evidence pack, plus an IDP for the developer experience afterwards. These are complements, not competitors.

Is any platform "HIPAA certified," and what does HIPAA actually require from your deployment platform?

No platform is HIPAA certified, because the US Department of Health and Human Services runs no certification program for cloud vendors. AWS says it plainly: "There is no HIPAA certification for a cloud service provider (CSP) such as AWS" (AWS). Microsoft says the same, that "there is currently no certification program approved by the US Department of Health and Human Services (HHS) through which a CSP acting as a business associate could demonstrate compliance with HIPAA" (Microsoft Azure). Google Cloud agrees that "there is no certification recognized by the US HHS for HIPAA compliance" (Google Cloud). Any vendor calling itself "HIPAA compliant," Qovery included, is describing a BAA plus a documented control set, not a certificate. Ask what the BAA covers and read the scope.

Concretely, your deployment platform has to give you five things: a signed BAA, encryption at rest and in transit, audit controls over PHI access and infrastructure change, least-privilege access control per environment, and a documented backup and contingency plan. The first four map to the HIPAA Security Rule technical safeguards - access control, audit controls, integrity, and person-or-entity authentication and transmission security (45 CFR 164.312). The contingency plan is an administrative safeguard under 45 CFR 164.308.

Shared responsibility is where most teams get burned, so here it is in three layers for a bring-your-own-cloud setup:

1. Cloud provider (AWS, GCP, Azure, Scaleway) secures the physical infrastructure, the hypervisor, and the HIPAA-eligible services, and signs its own BAA with you. AWS requires a signed BAA before any of its HIPAA-eligible services touch PHI (AWS).
2. Qovery covers the infrastructure and platform layer it manages under its BAA: cluster provisioning, upgrades, RBAC enforcement, deployment orchestration, and audit logging.
3. You own the application logic, data classification, and who inside your company can read PHI. Qovery's own docs list this split, putting application security, data classification, access management, and monitoring on the customer side (Qovery HIPAA docs).

That split is not a loophole. As Microsoft puts it, "by offering a BAA, Microsoft helps support your HIPAA compliance, but using Azure ... doesn't automatically impart compliance" (Microsoft Azure). The one design decision that pays off most: enforce a hard separation between production, which holds PHI, and non-production, which holds none, using RBAC and separate accounts or clusters rather than convention.

Why do healthcare startups leave a managed PaaS in the first place?

Healthcare teams leave a managed PaaS for three recurring reasons: the PaaS will not sign a BAA on the plan they can afford, the cost curve breaks once PHI volume and traffic grow, and enterprise or hospital procurement demands primitives the PaaS does not expose.

The BAA-and-tier problem is real and specific. Render puts HIPAA behind its Scale and Enterprise workspaces (Render Docs); Fly.io signs BAAs but you have to confirm the terms for your account (Fly.io). Check the exact page and plan tier before you assume PHI is allowed.

Cost is the second driver. A PaaS margin sits on top of the compute you run, and the committed-use discounts that matter at scale - Reserved Instances, Savings Plans, and equivalents - only exist if the cloud account is in your name. The third driver is missing primitives: VPC peering into a hospital network, dedicated tenancy, a specific region for data residency, ownership of your KMS keys, and audit-log export into Splunk or Datadog. Payer and health-system contracts ask questions only the account owner can answer.

Here is the honest counter-argument. If you are pre-product-market-fit with small PHI volume and no cloud engineer, staying on a HIPAA-ready PaaS such as Aptible is usually the right call. Migration costs real engineering months, and a tiny team is better off shipping product than operating infrastructure.

How do you keep PHI protected while running the old PaaS and the new cloud at the same time?

The dual-run window is the riskiest phase of the whole project, because PHI briefly lives in two places under two different vendors. Treat migration as a data-flow problem: inventory every PHI path, get BAAs signed with every vendor on both sides before a single record moves, build the target landing zone with logging and KMS before any workload lands, then cut over one service at a time with PHI datastores last.

• Step 1 - PHI inventory and data-flow map. List which services store PHI, which process it, and which merely transit it. Everything downstream of that map is scoped.
• Step 2 - BAAs valid for the entire overlap. Every vendor in the path needs a signed BAA covering the full dual-run period: the source PaaS, the destination cloud provider, and your platform layer. Qovery signs a BAA for the infrastructure it manages (Qovery HIPAA docs).
• Step 3 - landing zone first. Stand up the VPC and subnets, KMS keys you own, CloudTrail-equivalent audit logging, IAM roles, and a backup and retention policy before the first workload moves.
• Step 4 - never copy production PHI into staging or preview environments. This is the most common technical mistake in this migration. Seed non-production with synthetic or anonymized data (an anonymized-dump approach such as Replibyte-style seeding), never a production dump.
• Step 5 - strangler-pattern cutover. Move stateless services first and PHI datastores last, with a documented and tested rollback path and a named owner who decides to roll back.
• Step 6 - collect evidence as you go. Capture deployment logs, access logs, and change approvals during the move so the audit becomes a byproduct instead of a second project.

Human error, not exotic attacks, is what turns this phase into a breach: the Verizon 2025 report found the human element present in 60% of breaches (Verizon DBIR). And the stakes are highest in this industry - healthcare has carried the most expensive data breaches of any sector for well over a decade, averaging $7.42 million per breach in 2025 (IBM).

How do you migrate to your own cloud without slowing your engineering team down?

Velocity does not die during the cutover, it dies in the six months after it, when a small team that used to ship on git push starts filing tickets for environments, IAM changes, and cluster upgrades. The rule is to keep three things intact from day one: git-push deployments, an isolated PHI-free environment per pull request, and RBAC that lets developers ship to staging without ever touching production.

The gap this protects against is well documented. The DORA research on software delivery shows top-performing teams deploy on demand with change lead times under a day, while lower performers deploy far less often with lead times measured in weeks (DORA 2024 report). A compliance migration that introduces manual gates is exactly how a fast team slides down a tier.

Treat compliance as a guardrail, not a gate. Per-environment RBAC, an audit trail on every deployment, and production approval separated from staging deploys give you the controls without the ticket queue. Non-negotiables to preserve: self-service environment creation, per-PR preview environments, fast rollback, and auto-stop on non-production so ephemeral environments do not blow up the cloud bill. And do not build a bespoke internal platform during a compliance migration. That is two hard projects at once. Buy the platform layer and spend your engineers on the product.

Here is where Qovery fits concretely. Qovery is HIPAA compliant and signs a BAA for the infrastructure layer it manages, and it deploys into your own AWS, GCP, Azure, or Scaleway account, or onto your existing Kubernetes cluster (Bring Your Own Kubernetes). That BYOC model is what keeps this from being an AWS-only story: a hospital that mandates Azure or a data-residency rule that forces Scaleway is handled the same way. On top of it you get git-push auto-deploy, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades so nobody on a five-person team owns control-plane patching, per-environment RBAC, and databases backed by managed cloud services. The audit logs and deployment history double as audit evidence.

To repeat the boundary, because precision is the point: the Qovery BAA covers the infrastructure Qovery manages. It makes the technical safeguards easy to operate and easy to prove, and it sits alongside, not instead of, your own BAA with your cloud provider and your own application-level obligations for how PHI is handled.

What does a HIPAA-compliant migration cost, and how long does it take?

Compare options on 24-month total cost of ownership, not sticker price: the cloud bill in your own account (where Savings Plans and committed-use discounts stay in your name), platform or partner fees, and the engineering months you would otherwise spend on platform operations and audit evidence. For a healthcare startup with 5 to 15 engineers, a realistic PaaS-to-cloud migration takes months, not weeks, and the platform decision drives most of the recurring cost after it. McKinsey's research on cloud migrations found that these projects routinely overshoot both budget and schedule, so build in contingency and do not plan for the happy path (McKinsey).

A HIPAA-specialized PaaS earns its premium when the team is tiny, PHI volume is low, there is no cloud engineer, and you need a signed BAA plus a completed security questionnaire this quarter. Owning your cloud account wins when data volume is growing, procurement comes from enterprises or health systems, you need specific managed services or regions, and cost discipline through committed-use discounts matters. With a BYOC setup the cloud bill and any discounts stay in your name, which also simplifies the auditor's review because the infrastructure and logs are yours, while the infrastructure layer itself is covered by Qovery's HIPAA compliance and BAA.

Before you commit, run this four-question checklist. It is the fastest way to expose a plan that looks compliant on a slide and falls apart in an audit:

1. Do we have a BAA with every vendor touching PHI, and do we know exactly what each one covers?
2. Who owns day-2 operations after the partner leaves?
3. Can a developer ship to staging without filing a ticket?
4. Can we produce a full deployment audit trail in one query?