Moving a live booking platform from Ruby to .NET without stopping it

The problem

Vialuxury sells hotel stays with the extras included: dinners, wellness, experiences. Their platform was built in Ruby on Rails, and it worked. It was quick to change and the team knew it well.

Two things had become a problem. It had become expensive, and at busy times it fell behind on hotel availability updates, so the prices on the site could lag behind what hotels had released. Rewriting it in one go was not an option. Bookings come in every hour of the day, and years of business rules lived in the code, some of them in files rather than the database.

What we did

We built a new .NET core next to the Ruby one and moved the platform over one area at a time. Both systems run against the same Postgres database. Rails still owns the schema and .NET maps onto the existing tables, so switching an area over is a routing change that can be undone.

We started with accounts and passwordless sign-in, then finance reporting and invoicing, hotel availability, cancellations and refunds, and the sync of all content from the CMS. Checkout and payments go last.

Nothing took over until it matched Ruby on real data. A parity harness runs the Ruby and .NET versions side by side against the same CMS content and compares every row they write. Checkout runs in shadow mode: every live order is also calculated by .NET and compared with what Ruby charged.

What was hard

Rules outside the database. Email templates, discount rules and a partner list lived in Ruby files and constants. They had to be found by reading code, not data, and one list changed on the Ruby side after we had ported it.

A type system that let things slide. Hotels and packages both have a status, but 0 means draft for a hotel and published for a package. Ruby read some whole numbers as decimals and turned missing amounts into zero without complaint. The parity runs caught these one at a time, and a few differences turned out to be Ruby bugs that the .NET version now fixes.

Two systems, one database. Ruby's background jobs still run against the same tables. An old nightly job could overwrite a field the .NET side had just set, and removing a Ruby job could quietly stop something that depended on it. Every change started with finding who else writes to that table.

A rollback. The first switch of cancellations to .NET was undone the same day: under production load, background jobs on one server held locks the others were waiting for. It went live again four days later.

What changed

• Hiring is easier. There are more .NET developers to choose from than Ruby ones.
• When Ruby is switched off in October 2026, Vialuxury runs one stack instead of two. Until then it stays up as a fallback, which the business asked for.