Lasken cuts 3-year TCO 58% in a 6-week healthcare-platform migration to AWS

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 in November and December 2024, structured on AWS’s migration methodology — Assess, Mobilize, and Migrate & Modernize — and run with daily stand-ups, weekly status to the client sponsor, and disciplined risk and change control throughout.

Assess. VeUP started by taking the existing estate apart on paper: analyzing the source environment, pinning down the requirements, and putting an as-is/to-be architecture and migration strategy in front of Lasken for sign-off. The business case came down to a three-year total-cost-of-ownership comparison: what Lasken would have to build on its own to get HA, DR, separate environments, and GDPR-grade security controls, 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, with a week of post-production support behind it. The migration wrapped in mid-December 2024, the platform went live in production in January 2025, and the engagement carried straight 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.