How a Senior-Living Healthtech Startup Consolidated Its Platform onto AWS with Zero Data Loss - Horus Technology Skip to content
← Back to Blog

How a Senior-Living Healthtech Startup Consolidated Its Platform onto AWS with Zero Data Loss

Migration from Supabase, Clerk, and Vercel to Aurora PostgreSQL, Cognito, and ECS Fargate in a single AWS account

An early-stage healthtech company serving senior-living and assisted-living facilities ran its product across four separate vendors. Horus Technology moved its database, users, files, and web application into one HIPAA-eligible AWS account, defined entirely in AWS CDK, and cut over to production with every table reconciled and zero mismatches.

0

data mismatches across 36 production tables at cutover

70

users across 9 facility organizations migrated with roles intact

1

AWS account for data, sign-in, hosting, and AI

The customer

The customer builds AI tools for senior-living facilities. Caregivers record notes during their shifts, and the platform turns those notes into resident reports, health alerts, and updates for families. The platform holds resident health information, so data protection is a core product requirement. Its AI features already ran on Amazon Bedrock.

The challenge

Everything other than the AI ran on third-party services: PostgreSQL on Supabase, authentication on Clerk, hosting on Vercel, and messaging on MongoDB. That arrangement caused three problems:

  • Rising cost: The authentication tier needed for multi-facility organizations was roughly five times the company's existing authentication cost.
  • A harder compliance story: Larger facility groups ask about HIPAA and SOC 2 before they run a pilot. Describing controls across four vendors was much harder than pointing to one AWS account.
  • No room for downtime: Facilities were live, and caregivers use the app during shifts. No resident data could be lost, and no user could be locked out.

Our approach: build a parallel copy, then cut over

We followed one rule throughout: build a complete one-to-one copy of the platform in the customer's AWS account and leave production untouched until the customer had tested the copy and chosen the cutover window.

  • Discovery: We inventoried the database (tables, row counts, and row-level security policies), the authentication setup, environment variables, scheduled jobs, and firewall rules. Discovery also surfaced security issues in the legacy stack, and the target design was built to close them.
  • Infrastructure as code: The whole environment is defined in AWS CDK (TypeScript) as twelve CloudFormation stacks covering networking, the security baseline, storage, the database, authentication, hosting, messaging, and the CloudFront WAF, backed by about 230 infrastructure tests. The first seven stacks were deployed in the first build week.
  • Data layer: PostgreSQL moved from Supabase to Amazon Aurora PostgreSQL Serverless v2 in private subnets. We used scripted, repeatable dump-and-restore tooling and a reconciliation harness that compares row counts and per-table checksums between source and target. Profile photos and file attachments moved to Amazon S3.
  • Identity: Users moved from Clerk to an Amazon Cognito user pool, keeping facility, organization, and role mappings. Users sign in with Google or an email code. Sign-in email is sent through Amazon SES from the customer's own domain.
  • Hosting: The Next.js application moved from Vercel to containers on Amazon ECS Fargate in private subnets, autoscaling from one to three tasks behind an Application Load Balancer. Amazon CloudFront and AWS WAF sit in front, using managed rule sets and rate limiting. This kept the firewall protection the customer had on Vercel, and the load balancer only accepts traffic that comes through CloudFront.
  • Delivery pipeline: Pushes to the customer's GitLab repository trigger AWS CodePipeline, which builds a container image with AWS CodeBuild, stores it in Amazon ECR, and rolls it out to ECS. Infrastructure changes deploy from a separate repository through an OIDC deploy role, with no long-lived keys.
  • Scheduled jobs: An hourly report-drafting job that ran on Vercel cron now runs on an Amazon EventBridge schedule.

A HIPAA-eligible security baseline

The customer's whole platform, including its existing Bedrock workloads, now runs in one AWS account built only on HIPAA-eligible services:

  • A customer-managed AWS KMS key with automatic annual rotation encrypts Aurora, DynamoDB, and every S3 bucket that holds resident data.
  • Public access is blocked on all buckets, and the database cannot be reached from the internet.
  • AWS CloudTrail records activity across all regions with log file validation, and administrators sign in through AWS IAM Identity Center.
  • Application secrets and database credentials are stored in AWS Secrets Manager. Database maintenance runs through an AWS Systems Manager bastion with no inbound ports open.

We also wrote a HIPAA-eligible architecture and SOC 2 readiness document. It maps the controls to the SOC 2 trust services criteria and lists the remaining gaps, which gives the customer a concrete starting point for an audit.

The cutover

The team ran final readiness checks and a rehearsal on that day's production copy, then froze the application. Data was loaded and verified about 23 minutes into the freeze. We reconciled every table and verified sign-in, admin and caregiver access, and the live application on the production domains together with the customer. The freeze was planned for 60 minutes and, with the customer's agreement on the call, ran 95 minutes, mostly to fix a build issue and an application routing change. The old stack was kept intact during a seven-day hypercare period so the switch could be reversed if needed. Hypercare closed with no incidents, and every run of the hourly report job succeeded.

Results

Migration outcomes
MeasureResult
Data integrity36 of 36 production tables reconciled with zero mismatches (row counts and per-table checksums)
Users70 users across 9 facility organizations migrated with roles and organization membership preserved
TimelineKickoff in August 2026, production cutover in October 2026
RepeatabilityAll infrastructure defined in AWS CDK, so the customer can redeploy or extend it
FundingDelivered as an AWS Partner-funded proof of concept

The customer can now tell larger facility groups that its data, identity, hosting, and AI all run in one AWS account, on HIPAA-eligible services, with customer-managed encryption and a full audit trail.

AWS services used

Amazon Aurora PostgreSQL Serverless v2, Amazon Cognito, Amazon ECS on AWS Fargate, Elastic Load Balancing, Amazon CloudFront, AWS WAF, AWS CodePipeline, AWS CodeBuild, Amazon ECR, Amazon EventBridge, Amazon S3, Amazon DynamoDB, AWS KMS, AWS CloudTrail, Amazon CloudWatch, AWS IAM Identity Center, AWS Secrets Manager, AWS Systems Manager, Amazon SES, Amazon SNS, AWS Lambda, AWS CDK, and Amazon Bedrock.

Planning a move to AWS?

Horus Technology helps startups and regulated businesses move off fragmented vendor stacks and onto AWS. We start with discovery, build a parallel environment in code, reconcile the data, and plan a rollback for every cutover. Many of these projects qualify for AWS Partner funding. See our AWS consulting services or contact us to talk through your migration.

Get started

Tell us what you're trying to solve.

AWS architecture, a GenAI pilot, document processing, a migration off another cloud — tell us where you're stuck and we'll tell you if we can help. We build in your own AWS account, so what's yours stays yours.