A monolith, migrated with no downtime.

THE SITUATION

A travel booking platform had been running for nearly a decade on a single dedicated server in a colocation facility. It handled flight and hotel search, booking management, payment processing, and supplier integrations; all from one machine. The setup worked until it did not: the server was aging, the facility was raising prices, and a recent near-miss with a disk failure made it clear that the single point of failure was no longer acceptable for a business processing real-time bookings around the clock.

The platform was a classic LAMP monolith; PHP application layer, MySQL database, no containerisation, no orchestration, deploys done by SSH and hope. The team knew AWS was the right destination but were intimidated by the complexity of the migration. They could not afford downtime: bookings came in at all hours, from time zones they did not control, and every minute of outage meant lost revenue and damaged trust with travel suppliers.

THE MIGRATION

The plan was built around one principle: migrate the data first, then the application, and never touch both at the same time. MySQL on the old server was set up as a replication source. An RDS Aurora instance in AWS was configured as a replica and allowed to catch up completely: a process that ran in the background for several days while the live site continued serving traffic from the old machine. Once the replica was fully synchronised, a brief promotion cutover made Aurora the new primary. The application still pointed at the old server, but the database was now cloud-native with multi-AZ failover.

Next, the PHP application was containerised: a straightforward Dockerfile, nothing clever; and deployed to ECS Fargate behind an Application Load Balancer. Traffic was shifted incrementally using weighted target groups: 5% to the new service for a day, then 25%, then 50%, then 100%. At each step the team watched error rates, latency, and booking completion. There were no surprises because the data had been settled for a week before the first application byte moved.

THE RESULT

The entire migration happened during live traffic across a single month. At no point did the booking flow go down. The new setup runs across three availability zones with automated failover; if an AZ goes dark, the load balancer shifts traffic without human intervention. Every piece of infrastructure is declared in Terraform, version-controlled alongside the application code. The team went from praying over a single server to deploying with confidence, and the monthly infrastructure bill came in lower than the old colocation costs.