TicketSauce hits 99.99% uptime, cuts IT cost 30% migrating Rackspace to AWS
Amazon RDS for PostgreSQL
AWS DMS
AWS KMS
Amazon CloudWatchEvery ticket sold on TicketSauce’s platform touches its relational database. VeUP moved that core off Rackspace private cloud onto Amazon RDS for PostgreSQL in a Multi-AZ deployment via AWS DMS — encrypted at rest with AWS KMS, point-in-time recovery enabled, monitored through Amazon CloudWatch, and provisioned entirely as Terraform infrastructure-as-code.
The challenge
The database is the least forgiving component of a ticketing migration. TicketSauce’s platform processes payments and sells inventory that spikes violently at on-sale moments — so the relational tier had to move off the private-cloud host without extended downtime, land on infrastructure that survives an Availability Zone failure mid-on-sale, and come out the other side with the operational hygiene the legacy environment lacked: automated backups, tested recovery, at-rest encryption, and real monitoring.
The solution
VeUP treated the database as its own engineering track inside the four-week migration. AWS DMS replicated the production data from Rackspace into Amazon RDS for PostgreSQL running Multi-AZ — primary in one Availability Zone, synchronous standby in another — so the cutover window shrank to a controlled switchover rather than a long outage. The instance lives in a dedicated VPC DB subnet group with security groups scoping access to the application tier only; credentials sit in AWS Secrets Manager; storage and snapshots are encrypted with AWS KMS, with automated backups and point-in-time recovery enabled and snapshots landing in Amazon S3. Read pressure is kept off the database by design — Amazon ElastiCache (Redis) absorbs session state, and the auto-scaling Amazon ECS application tier connects through the load balancer path sized for on-sale bursts. The entire data layer is declared in Terraform, so staging and production are provably the same shape, and Amazon CloudWatch alarms watch connections, replication, latency, and storage headroom.
Production outcomes
| KPI | Result |
|---|---|
| Cutover | DMS-replicated migration with the RDS Multi-AZ database live at production cutover — the payment-processing workload’s relational core moved inside the four-week migration window. |
| Resilience posture | Multi-AZ synchronous standby with automated failover, automated backups and point-in-time recovery — availability engineering the single-host legacy environment could not offer, supporting the platform’s 99.99% uptime through peak on-sales. |
| Operational hygiene | KMS encryption at rest, Secrets Manager credential handling, CloudWatch monitoring and alarms, and a Terraform-defined data layer — the database now changes by code review, not console clicks. |
| Lessons & continuation | Running DMS replication ahead of cutover converts database migration risk into a rehearsable switchover; putting sessions in ElastiCache and bursts in the app tier lets the relational core stay right-sized while the platform absorbs on-sale spikes. |
AWS Secrets Manager
Amazon VPC (DB subnet group)
Amazon ElastiCache (Redis)
Amazon ECS + Auto Scaling
Amazon S3 (snapshots)