Armakuni Contact us
← All case studies

Hospitals expected their data every week.
The platform underneath it belonged to other people.

A U.S. clinical analytics provider ran on infrastructure it didn't own and reporting tools whose licenses grew with every user. We moved it to AWS in eight weeks, funded by AWS, then moved its production between AWS accounts with both running live and no missed pipeline run. Then we proved an open-source replacement for its warehouse and dashboards on real queries before starting the 800 GB, 200-dashboard migration.

Before

Every security decision was someone else's.

The reporting bill grew with every user.

After
0missed pipeline runs while production moved, as reported
25ECS clusters moved between accounts
  • Multi-AZ databases, managed SFTP and the AWS security stack, where there had been a single server and no visibility.

Every security decision was someone else's

The company's weekly clinical-data pipeline and embedded analytics serve providers and hospitals across the U.S. But every server, database and application lived in a third party's data center. It couldn't configure its own security controls or audit its own access logs, and it had none of AWS's native governance tools: no CloudTrail, no GuardDuty, no central secrets.

About 50 GB of clinical data arrived each week by SFTP and moved through five separate systems before anyone could use it, on tools built for on-premises use, with no alarm when a job stalled.

And the reporting bill grew with every user

The analytics layer served 300–400 users through about 200 dashboards embedded in the product, built on Snowflake and proprietary reporting tools. Every user added licensing cost and every gigabyte added compute and storage cost. Replacing them meant proving the alternative could match the same data volume, the same queries and the same embedded permissions, without anyone noticing.

Own it first, then prove before replacing

The work went in order: first the infrastructure came under the company's own control, then production moved between AWS accounts without a missed delivery, and only then did we prove an open-source reporting stack on real work before committing the whole library to it.

How we built it

3 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Eight weeks to infrastructure it owns
  2. Both accounts live, and the old one paid its minimum
  3. Prove the replacement on the hardest queries

Eight weeks to infrastructure it owns

Built withTransfer FamilyS3EC2ECSRDSControl Tower
Its own account SFTP into S3EC2 for SSISRDS SQL ServerControl Tower in eight weeks
The engineering

The first migration took eight weeks, with the whole cost covered by AWS Migration Acceleration Program (MAP) funding, and built the governance, networking, compute, database and security layers from scratch:

  • AWS Transfer Family receives the roughly 50 GB of weekly SFTP deliveries into S3, so there's no SFTP server to patch.
  • Windows EC2 instances keep the SSIS and specialist analytics components that need Windows, and application components run in ECS behind a load balancer.
  • RDS for SQL Server supplies Multi-AZ availability and managed backups, replacing a single SQL Server instance with no failover.
  • Control Tower sets up account governance, and CloudTrail, Config, GuardDuty, Security Hub, Secrets Manager and VPC Flow Logs give direct operational and security visibility, in a VPC across two Availability Zones with site-to-site VPN.

Components that can't be containerized should still move, and Windows on EC2 for two of them beat leaving the whole platform behind.

Both accounts live, and the old one paid its minimum

Built withECSMySQLControl Tower
The old accountIts own account 25 ECS clusters25 ECS clustersTwo MySQL clustersTwo MySQL clusters both live, the old one at its minimum
The engineering

A later move covered 25 ECS clusters and two MySQL clusters holding 15–20 databases, from one AWS account to a new Control Tower account. The catch was contractual: the original account had to keep at least $10,000–$12,000 of monthly workload running throughout.

So services moved in stages, sequenced so that obligation was met at every point. The team checked database integrity and service capacity, then ran a complete data-pipeline cycle in the destination before the old environment was reduced. As reported, DNS never changed and no pipeline missed a run.

Why: for a healthcare data supplier a missed weekly delivery means a clinician missing data they expected, so the cutover plan is a clinical commitment.

Prove the replacement on the hardest queries

Built withPostgreSQLApache SupersetSnowflakeRDSECSFargate
The replacementSnowflake SQL translatedFive to eight dashboards rebuiltEmbedding and rolesResults match
The engineering

Open-source tools exist. The question was whether they could carry this workload without rebuilding the product around them. The analytics proof of concept tested PostgreSQL and Apache Superset against the real reporting work:

  • We translated representative Snowflake transformations into PostgreSQL-compatible SQL and compared the results with the original queries, since the two don't share the same functions or materialized-view patterns.
  • We rebuilt five to eight dashboards covering the range of filters, visualizations and query complexity in the library.
  • We exercised token-based embedding, session handling and Viewer, Designer and Admin roles inside the SaaS application, because the dashboards live inside the product.
  • Validation covered query-result parity, embedded access and dashboard behavior before committing the whole library.

The proof of concept ran Amazon RDS PostgreSQL with Multi-AZ replication and Superset on ECS/Fargate, with a CI/CD pipeline and the same security services.

What we'd tell another CTO

1Own your infrastructure before you optimize it, because you can't secure what you can't audit, and move the parts that can't be containerized anyway, as Windows on EC2 did here.
2Run the full pipeline in the destination before you reduce the source, and treat a contract minimum as a design constraint, since it decides the order of the move. A replacement reporting stack has to be proved on your hardest queries and your embedded permissions, because that's where switches fail.

What else changed

  • Infrastructure it owns and governs, moved in eight weeks, funded by AWS MAP.
  • A proven open-source path: PostgreSQL and Superset matched query results, embedded access and dashboard behavior on a representative set.

What comes next

Completing the move from Snowflake and the proprietary dashboards to PostgreSQL and Superset, then retiring the licenses.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

Replacing licensed reporting with software the company owns is our Build your own offer: we build it, the company starts paying us when it stops paying the licenses, and after two years it owns the software outright, in its own AWS account. Some tools are worth renting, and we'd say which.

The warehouse move would follow AK Evolve's discipline, with characterization tests pinning what each query returns today, right or wrong, and every translated transformation matching them before it replaces the original, with a person reviewing and merging every change. The HIPAA evidence would come from the controls as they run, and AK Run's AI agents would take the first look at every pipeline alert, for a named engineer to confirm and ship the fix with a test. For the companies we run, the median AWS bill falls 40% in the first quarter.

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop