Zero-downtime AWS migration that cut infrastructure costs by 25%

Stanza Living's growth from a Bangalore-based startup to a 30-city, 50,000-resident co-living network happened faster than their infrastructure could accommodate. Their entire technology stack — booking engine, resident app backend, payment processing, and internal operations tools — ran on bare-metal servers in a single Bangalore data centre. This single point of failure had already caused two major outages in the preceding 12 months, each lasting more than four hours and generating thousands of resident complaints.

The engineering team was spending an estimated 40% of their collective time on infrastructure firefighting: responding to disk space alerts, patching servers manually, and managing deployments that required 3 AM maintenance windows to avoid peak usage. Actual product development had slowed to a fraction of its earlier pace. Senior engineers were leaving, citing frustration with the operational burden rather than product work.

Migration could not be scheduled around a quiet period — co-living accommodation is occupied year-round. Any resident-facing downtime would affect check-in processing, payment collection, maintenance request submission, and security access control. The business case for migration was strong, but the execution risk was significant enough that two earlier migration proposals had been shelved by the board.

We opened the engagement with a comprehensive 7R (Rehost, Replatform, Refactor, Repurchase, Retire, Retain, Relocate) analysis across Stanza Living's 80-service portfolio. The majority — 68 services — were strong lift-and-shift candidates that could move to EC2 with minimal modification. Six core services representing the booking engine, payment gateway integration, and resident authentication required containerisation before migration to ensure they could be horizontally scaled on AWS EKS.

Our migration strategy centred on a parallel-run architecture: for each service, we brought up the AWS equivalent and ran it in shadow mode, validating output against production for a minimum of 72 hours before cutting traffic over. Automated switchover scripts with built-in rollback triggers meant that if a service degraded beyond defined thresholds post-cutover, traffic would revert to on-premise within 90 seconds without manual intervention.

FinOps was designed in from day one rather than retrofitted. We modelled every service's AWS cost profile during the architecture phase, selecting Reserved Instances for predictable baseline workloads and Spot Instances for batch processing jobs. Terraform was used to codify all infrastructure, enabling cost governance through code review before any resources were provisioned.

The full migration to AWS — spanning EC2, EKS, RDS (PostgreSQL and MySQL), CloudFront, S3, and ElastiCache — was completed in five months with zero minutes of resident-facing downtime. All 80 services were migrated across eight phased cutover weekends, each preceded by a full dry run and followed by a 48-hour hypercare period with our engineers on standby.

Datadog observability was deployed across the entire stack, providing end-to-end distributed tracing for the first time in Stanza's history. The engineering team could now trace a slow API response from the resident app all the way through the service dependency chain to the database query causing the delay. Mean time to resolution for production incidents dropped from 4.2 hours to 38 minutes within the first month post-migration.

A weekly FinOps review cadence was established with the CTO and Head of Engineering. AWS Cost Explorer dashboards, custom-tagged by product area and environment, gave leadership real-time visibility into spend. Right-sizing recommendations from AWS Compute Optimizer were reviewed and actioned fortnightly. Within three months of full migration, monthly cloud spend had settled 25% below the equivalent on-premise cost — while running at three times the deployment frequency.