Lasken Health

Lasken GmbH operates a digital platform for secure patient information sharing across healthcare providers in the EU. Because the platform processes personal health information, GDPR and EU health-data requirements — data residency, encryption, and controlled access — shaped every architectural decision.

The application was a classic three-tier stack built by an external agency: an Angular (TypeScript) single-page front end and ASP.NET (.NET 8 / C#) APIs on Windows Server with IIS, backed by Microsoft SQL Server 2022, running on three customer-managed virtual machines in a single production environment. There was no development or test path, so untested code deployed straight to a live healthcare platform; deployments were manual; and there was no high availability, no disaster recovery, and no infrastructure-as-code. Every release carried production risk. Lasken needed verifiable EU data sovereignty through in-region hosting, a real software-delivery lifecycle, production high availability, and a defensible, auditable architecture — and it needed to move off the agency’s hosting onto an AWS estate it could govern and scale itself.

VeUP delivered the migration as a six-week engagement (Nov 4 – Dec 13, 2024) structured on AWS’s migration methodology — Assess, Mobilize, and Migrate & Modernize — under a signed Statement of Work with formal delivery governance throughout: a Project Initiation Document, daily stand-ups, weekly status reporting to the client sponsor, risk and issue management, and formal change control.

Assess.The engagement began with a structured assessment of the existing application estate: systems analysis of the source environment, a detailed requirements document, and an AS-IS/TO-BE Architecture & Migration Strategy completed for client sign-off. The business case was quantified as a three-year total cost of ownership analysis comparing a full-capability on-premises equivalent — what the customer would have to build to achieve HA, DR, separate environments, and GDPR-grade security controls on its own — against the AWS target state.

Mobilize. Mobilization established the foundation before any workload moved: a multi-account structure in AWS Organizations with one management account plus dedicated Dev, Test, and Production accounts for environment isolation and consolidated billing, with the entire estate defined in Terraform from day one. The security baseline went in at the same layer — per-environment VPCs with public, private-application, and private-database subnet tiers, security groups chained by reference so each tier accepts traffic only from the tier in front of it, AWS WAF, IAM roles scoped to function, AWS KMS for encryption keys, and AWS Secrets Manager for secrets and certificates.

Migrate & Modernize. VeUP applied deliberate 7Rs dispositions per tier rather than a uniform lift-and-shift: replatform the web tier from Windows Server/IIS to Linux/Apache on Amazon EC2, eliminating Windows licensing on that tier entirely; rehost the ASP.NET (.NET 8) API tier onto Windows EC2 instances unchanged, preserving full application compatibility with zero code-change risk on a regulated workload; and replatform the database from self-managed SQL Server to Amazon RDS for SQL Server 2022, Multi-AZ in production, gaining managed failover, automated backups, point-in-time recovery, and encryption at rest for patient data. The on-premises SMTP relay was replaced with Amazon SES for transactional patient notifications. All three environments were built from Terraform, with AWS CodeBuild and AWS CodePipeline promoting releases from Git source control through Dev → Test → Production, and Amazon CloudWatch providing metrics, logs, and alarms across every environment.

Cutover and validation. The build ran as a greenfield parallel deployment: the existing production platform kept running throughout, which served as the standing rollback position. VeUP created and configured the RDS cluster by importing the database schemas and data structures; the production data cutover was executed on the customer side in line with the agreed plan, keeping the handling of live patient data with the data controller. Validation ran through unit testing, a client demonstration, and recorded walkthrough videos, followed by a one-week post-production support period. The project review completed on December 13, 2024, migration completed in December 2024, and the customer confirmed production go-live on January 7, 2025 — with the engagement continuing into a follow-on optimization phase.

The target estate was designed against the six pillars of the AWS Well-Architected Framework. Operational excellence: every environment is reproducible from Terraform with remote state and state locking, releases promote through CodeBuild/CodePipeline, and CloudWatch provides metrics, logs, and alarms — with technical and operating documentation handed over at close. Security: defense in depth for patient data — AWS WAF managed rules at the edge, security groups chained by reference, private subnets for the API and database tiers, an RDS instance that is encrypted at rest and not publicly accessible, KMS key management, Secrets Manager, and account-level isolation under AWS Organizations. Reliability: production spans two Availability Zones, Auto Scaling groups replace unhealthy instances automatically, and RDS Multi-AZ provides synchronous standby failover with automated backups and point-in-time recovery. Performance efficiency: each tier runs in its own Auto Scaling group with launch templates, so capacity tracks demand rather than being fixed to provisioned VMs. Cost optimization: the Linux/Apache replatform eliminated Windows web-tier licensing, Dev and Test run single-AZ as a deliberate cost tradeoff, and a quarterly TCO refresh with a monthly cost review was established as the continuous-improvement mechanism. Sustainability:demand-tracking, right-sized capacity replaces permanently provisioned hardware.

A three-tier design in the AWS Europe (Frankfurt) Region, eu-central-1, chosen for verifiable EU data residency: Amazon Route 53 to an internet-facing Application Load Balancer with AWS WAF attached, a Linux/Apache web tier in public subnets, an internal Network Load Balancer to the Windows/.NET API tier in private subnets, and Amazon RDS for SQL Server Multi-AZ in dedicated private database subnets — annotated against the AWS Well-Architected pillars.