Travel · Cloud & platform · 2025
Moved a booking engine off Ruby without downtime
A legacy Ruby booking engine rebuilt on .NET and migrated with 450,000+ historical bookings intact and no service interruption.
0
hours of downtime in migration
450K+
historical bookings migrated
500K+
users served on the new stack
What it meant
Bookings never stopped during the migration, and the platform came out on a stack the team could hire for and extend.
The challenge
A luxury travel platform serving over half a million users and 250+ hotel partners ran its booking engine on an ageing Ruby stack. Hiring against it was slow, the deployment story was hybrid and fragile, and 450,000+ historical bookings had to survive any move intact. Booking flow could not stop - the business runs on it continuously.
Our approach
We rebuilt the booking engine on .NET and defined a zero-downtime migration path that moved traffic incrementally rather than in a single cutover, with the historical booking corpus migrated and reconciled ahead of the switch. The deployment is hybrid by design - on-premise alongside AWS - with PostgreSQL and RabbitMQ carrying persistence and messaging. We also re-engineered the matching engine that turns hotel overcapacity into personalized offers, so the commercial logic improved rather than merely surviving the port.
Tech stack
- .NET
- PostgreSQL
- RabbitMQ
- AWS
- React
Client profile
Luxury travel platform, 250+ hotel partners
Client named on request, with their consent.
What changed
Before: ruby booking engine. ageing stack, fragile hybrid deploy. booking core; inventory; offers; 450K+ bookings. slow to hire for, hard to extend. After: .net booking engine. on-prem alongside aws. booking core · .net; postgresql; rabbitmq; matching engine. traffic moved in slices, never in one cutover. The measured change: 0 hours of downtime, 450K+ bookings migrated.
01 BEFORE
ruby booking engine
ageing stack, fragile hybrid deploy
- booking core
- inventory
- offers
- 450K+ bookings
slow to hire for, hard to extend
0
hours of downtime, 450K+ bookings migrated
02 AFTER
.net booking engine
on-prem alongside aws
- booking core · .net
- postgresql
- rabbitmq
- matching engine
traffic moved in slices, never in one cutover
Want a result like this?
Tell us the problem - we’ll tell you, plainly, how we’d get there.