Mrs Mactivity · Education technology
Case study
Moving a live booking platform to AWS, without a minute offline
tobook's booking platform had grown up on Azure. We rebuilt its hosting on AWS, in code, and moved it across while bookings kept arriving.
- Client
- Industry
- Hospitality and booking
- Delivered through
- Hatcha, our UK sister company
Booking app · last 90 days
0.00%
server errors
Results
The results
Zero
downtime during the move
The new platform was built alongside the old one and tested before any customer used it.
0.00%
server errors on the booking app in the 90 days to September 23, 2026
Measured across every request the booking app served in that time.
One command
rebuilds the entire platform
Every part of the infrastructure is defined in code.
The story
The story
Services
Delivered by our team through Hatcha, PanamaGulf's UK sister company.
The challenge
tobook’s booking platform had grown up on Azure. It worked, but the hosting was sized for assumptions that hadn’t been revisited, and releasing a change was slower and more manual than a growing product can afford.
The main constraint was uptime. tobook’s customers are corporate bookers with deadlines, and the platform couldn’t go offline for a migration window, on a weekend or at three in the morning, because somewhere a booking was being confirmed.
What we did
We rebuilt the hosting on AWS with every part of it defined in code, so it can be recreated consistently and every change is recorded. The application, the database and the public site each moved onto services suited to how tobook uses them.
Then we replaced the release process with a pipeline, so shipping a change is now routine.
The result
There was no downtime during the move. Over the 90 days to September 23, 2026 the booking app returned 0.00% server errors.
How we work with tobook
We still look after the platform. It is monitored, the pipeline is written down and a named engineer knows how it fits together. When something needs changing, tobook asks in a shared channel and gets an answer the same day.
How it went
How the move went
Most of a migration happens before the day itself. This is the order we worked in.
We documented the existing setup
Every running service, scheduled job, credential and DNS record. Migrations tend to go wrong on things that weren't documented, so we documented them first.
We built the new platform in code
We described the platform we wanted in code and built it from that. This took longer up front and means the platform can be rebuilt identically at any time.
We ran both platforms side by side
The new platform served real traffic in a staging environment while the old one stayed live. Every part of the booking flow was tested against the new database before anything moved.
We rehearsed the cutover
We practiced the domain records, certificates and the switch itself in advance and wrote down the timings, so the real cutover repeated a rehearsal.
We switched over with no downtime
Bookings kept arriving and purchase orders kept being chased. No customer had to be warned that the platform would be unavailable on Saturday night.
We stayed on to support it
The platform is monitored, the pipeline is documented and a named engineer knows how it is put together. Releases went from an event to a routine.
Technology
What sits underneath it now
Four tiers, each doing one job and each described in code.
Edge
Traffic arrives on a global delivery network
Requests hit a global delivery network before they reach anything of tobook's, so pages and assets are served close to the person asking for them. Production and staging are entirely separate paths, with no route from one to the other.
- Global delivery network
- HTTPS everywhere
- Staging on its own path
Application
The booking app runs in containers, in more than one copy
Production always runs more than one copy of the application behind a load balancer, so a single failure doesn't take the app down. The containers sit on a private network with no inbound route from the internet.
- Containerized
- More than one copy, always
- No public inbound
Data
The database keeps a month of history
A managed relational database with automated backups and a thirty-day point-in-time recovery window, so any moment in the last thirty days can be restored.
- Managed database
- 30-day recovery window
- Credentials generated automatically
Release
Every release goes through a pipeline
Every deployment runs through a pipeline. The pipeline authenticates with short-lived credentials, so no long-lived cloud keys are stored anywhere, and a rule in the repository refuses any change that hasn't been through staging first.
- No long-lived cloud keys
- Releases must pass staging
- Infrastructure in code
Scale
What it handles now
The platform has been on AWS for several months. These figures cover the most recent quarter.
- requests served across the platform
- 2.1M
- server errors on the booking app
- 0.00%
- of point-in-time database recovery
- 30 days
Measured across tobook's booking app, public site and recommendations platform over the 90 days to September 23, 2026.
More work
Other case studies
River Global PLC · Financial services
Separating a listed company's website from the business that was sold
Read the case studySupersonic Phonic Friends · Education
Rebuilding a phonics platform in time for the new school year
Read the case studyCompound Equity Group · Financial services
A brand and website design for a new investment group
Read the case study
Have a project in mind?
Tell us what you're planning and we'll reply within one business day. You can book a free 30-minute call with Louie as soon as you've sent it, and we'll follow up with a written estimate.