How to move a live platform to AWS without downtime

Moving a live application to a new cloud provider sounds like a weekend job with a maintenance page. For a platform that takes bookings, orders or payments around the clock, a maintenance page means lost revenue and customers who notice. The good news is that a well-planned migration doesn’t need one.

We recently moved tobook’s booking platform from Azure to AWS with no downtime. This article sets out the approach we used, in the order we used it. It applies whether you’re leaving Azure, another cloud provider or servers in your own building.

1. Document everything the current platform does

Migrations usually go wrong on things nobody wrote down. A scheduled job that sends invoices at 2am, a certificate renewed by hand once a year, a firewall rule added for one supplier: none of these show up in the application code, and each one stops working if it’s left behind.

Before building anything, make a full list of what is running today:

• every application, worker and scheduled job, and what triggers it
• every database, file store and queue, with its size and how quickly it changes
• every domain, DNS record and certificate, and who renews them
• every credential, API key and connection to a third party
• every email route, from password resets to alerts
• monitoring, backups and anything that would page someone at night

This list becomes the checklist for the rest of the project. If something is on the old platform and not on the list, it will not be on the new one.

2. Build the new platform in code

Describe the AWS platform in code with a tool such as Terraform, then build it from that code. It takes longer up front than clicking through the AWS console, and it pays for itself several times during the migration.

Infrastructure in code means you can build a staging copy that matches production exactly. Every change is reviewed and recorded, so you can see what changed between rehearsals. And if something goes wrong late in the project, you can tear the environment down and rebuild it in minutes.

It also helps after the move. A platform described in code can be handed to another engineer, audited for security or rebuilt in another region without relying on anyone’s memory.

3. Run both platforms side by side

With the new platform built, run it alongside the old one in a staging environment. Point a copy of the application at it, load a recent copy of the data and test every journey that matters to your customers: signing in, searching, booking, paying, receiving emails and anything that talks to a third party.

This is where the list from step one earns its place. Work through it line by line and confirm each item works on AWS. Anything that fails at this stage can be fixed before a customer sees it.

4. Plan how the data moves

Moving the application itself is usually straightforward. The data is harder, because it keeps changing while you move it.

For a small database that changes slowly, a short pause in writes while the final copy is taken may be acceptable. For anything busier, the usual approach is to copy the data ahead of time and then keep the new database in step with the old one until the moment of the switch. AWS Database Migration Service and native database replication can both do this, and the right choice depends on your database engine and how much it changes.

Whichever method you use, check the data on both sides before the switch. Compare row counts and totals for the tables that matter and spot-check recent records. Files in storage need the same treatment: copy them early, then sync the changes.

5. Rehearse the cutover

The switch itself should be the second or third time you’ve done it. Write a runbook that lists every step in order, who does it and how long it should take, then run it end to end against staging.

A few days before the real cutover, lower the TTL on the DNS records you’ll change, to five minutes or less. That way, when you point the domain at AWS, browsers and networks pick up the change quickly. Issue the certificates for the new platform in advance too, so the first request to AWS is already served securely.

Decide in advance what would make you stop and switch back, and rehearse that as well. Keep the old platform running and able to take traffic until the new one has proved itself.

6. Switch, then watch

On the day, follow the runbook. Stop the data sync at the agreed point, confirm the final checks and move the traffic. Then watch the error rates, response times and the journeys you tested in step three. If the rehearsal went well, this part is uneventful.

Booking activity

1. 21:52Booking confirmed · Leeds City Suites
2. 21:57PO received · Glasgow Riverside
3. 22:00Traffic moved to AWS
4. 22:04Booking confirmed · Cardiff Bay Hotel
5. 22:09New request · Sheffield Park

Azure Retired

↓

AWS · London Live

Cutover

None

downtime

Bookings kept arriving

Keep the old platform available, but idle, for an agreed period afterwards. Once you are confident nothing is still pointing at it, shut it down and stop paying for it.

7. Support the new platform

A migration ends with a platform that someone has to run. Before you call the project finished, make sure monitoring and alerts go to the right people, backups have been restored at least once and the release process deploys to staging before production. Write down how the platform fits together while the details are fresh.

When to bring in help

Teams with experienced cloud engineers can run a migration like this themselves. If yours doesn’t, or the platform is too important to learn on, it’s worth working with a team that has done it before. Our cloud migration service follows the steps in this article, and once the move is done we can host and support the platform on AWS in London.