Migrating from Vercel to HIPAA-Aligned Architecture
How we moved a Next.js healthcare app off serverless hosting onto infrastructure where BAAs and HIPAA technical safeguards can be met—without touching existing product behavior.
Why this story exists
To show a concrete path from “we’re on Vercel and need to support HIPAA-regulated workloads” to “we run on BAA-eligible infrastructure with encryption, access controls, and audit logging”—without implying that any specific product is HIPAA compliant.
The Problem
The app started on a Next.js + Supabase stack, typically deployed on Vercel. Once the business needed to handle PHI and align with HIPAA, that setup was a blocker: no BAA with the host, limited control over data residency and auditability, and serverless boundaries that made consistent RLS and logging harder.
The Intervention
We ran a phased migration: verify BAA coverage with a cloud provider, stand up HIPAA-eligible services (PostgreSQL, App Service, Blob Storage, Key Vault), migrate auth and data read-only from the original stack, then harden encryption and audit logging.
The Result
The same app now runs on infrastructure that can be covered by a BAA, with encryption at rest and in transit, RLS, and application-level audit logs—laying the groundwork for a HIPAA-aligned program without asserting compliance for the product.
Any product that touches health data may eventually need BAA-eligible infrastructure. This case study is a template: what to verify first, what to migrate, and what to document—so you’re not starting from zero.
Why Vercel Wasn’t Enough
The app was a standard Next.js build (App Router, API routes, server components) with a managed Postgres-backed auth and storage layer. For HIPAA-aligned workloads we needed:
How do you move a live app onto HIPAA-eligible infrastructure without rewriting it or creating a compliance claim you can’t back up?
The work had to be:
Phased Migration: Legal → Infra → Data → Hardening
We followed a single plan: BAA first, then infrastructure, then data and auth, then security and audit. Each phase had clear acceptance criteria.
BAA Verification
Legal foundation before any new infra
We confirmed that the chosen cloud provider’s BAA is included in their standard terms (no separate contract). We verified which services are in scope (e.g. managed PostgreSQL, app hosting, blob storage, secrets) and documented that. No production PHI was moved until this was done.
- BAA coverage confirmed and documented
- Only HIPAA-eligible services used for PHI
- Subscription/effective date recorded for audit
Azure Foundation
Resource group, Key Vault, PostgreSQL, Storage, App Service
We created a resource group and enabled only the services we needed: Key Vault for secrets, Azure Database for PostgreSQL (Flexible Server) with SSL enforced and encryption at rest, a Storage account with HTTPS and TLS 1.2 minimum, and an App Service plan for the Next.js app. App settings and secrets were injected via CI (e.g. GitHub Actions) and/or Key Vault references so nothing lived in repo.
- PostgreSQL: SSL required, encryption at rest, backups configured
- Storage: secure transfer only, TLS 1.2+, encryption at rest
- App Service: HTTPS only, TLS 1.2, managed identity for Key Vault
Auth, Database, and Storage Migration
Read-only export → transform → load
Auth: We moved from the original provider’s auth to a session-based stack (e.g. NextAuth with a Postgres adapter). Users and MFA state were exported and imported; no deletion from the source.
Database: Schema was adapted (e.g. RLS functions that depended on the old auth were replaced with session variables set per request). Data was exported with pg_dump and imported into the new Postgres; row counts and relationships were verified.
Storage: Files were listed, downloaded, and re-uploaded to the new blob store with paths and metadata preserved. The app was updated to use the new storage client and URLs.
- RLS policies preserved and tested (e.g. cross-tenant access blocked)
- Connection layer sets session context (e.g. current_user_id) for RLS
- No destructive operations on the source environment
Encryption & Audit
Hardening and documentation
We verified encryption at rest and in transit for DB, storage, and Key Vault; turned on platform security features (e.g. Defender for Cloud free tier); and ensured application-level audit logging (who did what, when, from where) with a retention policy that meets common HIPAA expectations (e.g. 6 years). We documented config and decisions for future audits.
- Audit table append-only, RLS-protected, indexed for queries
- Retention and review process documented
- Security and encryption status documented in one place
What We Evaluated: Vercel, Netlify, Railway, Supabase, AWS, Azure
Several of these offer HIPAA BAAs, but at very different price points. We needed a full BAA-eligible stack (app host, database, storage). Below are real numbers from public pricing and vendor docs (prices approximate; confirm with providers).
Azure breakdown (minimal production)
Actual numbers we used for sizing
- Azure Database for PostgreSQL (Flexible Server, B1ms, 1 vCore, 2GB RAM): ~$30–40/month
- App Service (Basic B1, 1 vCore, 1.75GB RAM): ~$13–20/month
- Storage Account (Standard LRS, minimal usage): ~$5–10/month
- Key Vault (Standard): negligible at low secret volume
Total: ~$50–70/month for a full BAA-eligible stack (DB, app host, blob storage, secrets). No separate BAA contract—included in Microsoft Product Terms.
What We Achieved
What We’d Do Differently
Lock the migration plan in a single doc and do one substep at a time with explicit sign-off. It prevented scope creep and made it clear when we were “done” for each phase.
Keep the original environment intact (read-only migration, no decommission until after a long validation window). That made rollback possible and reduced risk.
Document the plan, move in small steps, and don’t burn bridges with the old stack until you’re sure the new one holds.
This story isn’t about one product.
It’s about a repeatable pattern for teams that need to:
- move off Vercel (or similar) when the workload requires BAA-eligible infrastructure
- keep the same app shape (Next.js, Postgres, blob storage) while changing where it runs
- avoid claiming “we’re HIPAA compliant” before testing and documentation are in place
That’s the kind of migration ReThread can help design and execute for healthcare and regulated verticals.
If you’re on Vercel (or similar) and need to support HIPAA-regulated data
if you want a clear migration plan and acceptance criteria
if you’d rather not guess at BAA and encryption requirements
Next step: