Platform migration playbook to keep bookings running during cutover

Most migration horror stories don't start with a bad platform. They start with a good platform and a bad cutover plan. The new system was fine. The data model was fine. What killed it was flipping the switch during a booking window, discovering that deposit records didn't map cleanly, and spending the next three weeks reconciling payments by hand while agents kept selling on top of a half-migrated database.

For a platform migration a tour operator actually survives, the volume you're processing matters more than the software you're moving to. Migrating 200 bookings a month is a weekend project. Migrating through peak season at 40k–60k bookings is a different animal — one where a two-hour data sync gap turns into hundreds of orphaned reservations and a support queue that never recovers.

This is a playbook for cutting over without stopping the money. It's organized around booking volume tiers, because that's what changes everything: the SLA gates you enforce, whether you run old and new systems in parallel, how you train, and how fast you can roll back when something goes sideways.

Why volume — not features — decides your migration risk

At low volume, you can afford ugly. Running maybe 300–800 bookings a month? Freeze sales for a Saturday, export everything, import it, spot-check the top 50 upcoming departures, reopen Sunday. Mistakes are cheap because there aren't many of them, and each one is manually recoverable.

The math flips fast. Around 5k monthly bookings you can't freeze sales without losing real revenue, and manually verifying records stops being an option — there are just too many. At 40k+ you're processing bookings faster than any human can audit, which means your migration has to be provably correct in flight, not verified afterward. The failure isn't "some data was wrong." It's "we didn't find out data was wrong until a customer showed up to a tour that the new system thinks was cancelled."

The pattern that repeats: operators plan the migration around the new platform's capabilities and completely underestimate the coordination cost of moving live operations. The database migrates in hours. Your suppliers, agents, OTAs, payment processors, and staff take weeks to fully move. That gap between "data moved" and "everyone's actually working in the new system" is where continuity dies.

The four volume tiers and what changes at each

Volume is the clearest way to understand what kind of migration you're actually dealing with. Each tier brings a different level of risk, a different cutover approach, and honestly a very different emotional experience for everyone involved.

The important insight buried in this table: the higher your volume, the less you're allowed to do a clean switch. Tier 0 operators get the luxury of a hard cutover. Tier 3 operators can never fully turn the old system off until the new one has proven itself under real load — which means running both simultaneously and reconciling them constantly. That's expensive and annoying, and it's also the only thing that keeps 80k bookings safe.

SLA gating: the checkpoints that stop a bad cutover from going live

The single most useful thing you can build before migrating is a set of gates — measurable conditions that must be true before you're allowed to advance to the next phase. Not "we feel good about it." Actual pass/fail criteria.

The mistake most operators make is treating go-live as a decision made in a meeting. It should be a decision made by data. If the reconciliation gate isn't green, you don't cut over, no matter what the calendar says or how much you've already paid the new vendor.

1. 1
   Data integrity gate — 100% of upcoming departures (next 90 days) matched between systems, with deposit balances reconciling to the cent. Sampling doesn't count here; upcoming trips get a full match.
2. 2
   Payment mapping gate — every open payment plan, deposit schedule, and refund-in-progress has a verified home in the new system. A single mismatched deposit schedule can send the wrong balance-due email to hundreds of customers.
3. 3
   Channel sync gate — availability and pricing from the new system push correctly to every OTA and reseller, verified with test holds that you then release.
4. 4
   Performance gate — the new system handles your peak-hour booking rate plus roughly 30% headroom without timeouts. Migrations that pass functional tests still fail here when real concurrency hits.
5. 5
   Rollback gate — you've actually tested rolling back, not just documented it. If you can't demonstrate a rollback in a rehearsal, you don't have one.

Each gate needs an owner and a hard threshold. The whole point of gating is that it removes emotional pressure from the launch decision. Nobody has to argue about readiness — the gate is either green or it isn't.

Parallel-run recipes: when both systems are live at once

For anyone above roughly 5k bookings a month, you'll run old and new systems side by side for a stretch. The question is how. Three patterns actually work depending on your risk tolerance.

Recipe A — Read-only shadow. The new system receives a copy of every booking but can't create or modify anything customer-facing. You use this to compare outputs: does the new system calculate the same balance due, the same commission split, the same VAT? Cheap to run, catches logic errors early, but doesn't test the new system under real write load.

Recipe B — Dual-write. New bookings get written to both systems simultaneously. Heavier to build but far more revealing, because now you're catching failures in the actual booking path, not just in reporting. The trap here is drift — if the two systems fall out of sync even slightly, you need automated reconciliation running constantly, or you'll trust a divergence you never noticed.

Recipe C — Segment split. You move one product line, one channel, or one region to the new system entirely while everything else stays on the old one. A day-tours operator might migrate single-day experiences first — simple, high volume, low blast radius — and keep multi-day packages on the old system until the new one proves itself. This limits damage to a segment you can afford to lose temporarily.

Here's a simple workflow visualization of how shadow, dual-write, and segment-split migrations progress.

Most Tier 2–3 operators end up combining these: shadow first to validate logic, then dual-write on a segment, then expand. The operators who get burned are the ones who skip straight to full dual-write across everything and can't tell which of forty divergences actually matters.

A quick real-world example: an inbound operator running around 22k bookings a month started with a two-week read-only shadow and found the new system was applying VAT differently on a specific package type — a discrepancy of maybe €40–€90 per affected booking. Small on paper. Across the affected volume it was a five-figure monthly leak that would have gone straight through on a hard cutover. They fixed the mapping before a single customer saw a wrong invoice.

Rollback scenarios you have to plan before, not during

Nobody wants to think about rollback while they're excited about the new platform. That's exactly why so many teams don't have one. A rollback plan written after something breaks is not a plan — it's a panic.

The core problem with rollback in booking systems is that it's never clean. If you cut over Monday and something breaks Thursday, you now have three days of new bookings, payments, and changes that only exist in the new system. Rolling back to the old database means either losing those or manually re-entering them. This is why granular, reversible cutovers beat big-bang ones at scale — the smaller the segment you moved, the smaller the mess if you have to reverse it.

1. 1
   The silent data corruption. Bookings look fine but a field is systematically wrong — wrong pickup times, wrong pax counts. Your rollback trigger here is a monitored threshold, not a customer complaint. Decide the number in advance: if more than X% of new bookings fail validation, you roll back.
2. 2
   The payment path failure. The new system takes bookings but payments aren't settling or are double-charging. Same-hour rollback decision. Have the merchant routing fallback documented and pre-authorized.
3. 3
   The performance collapse. New system falls over under load. If you built dual-write, you can route new bookings back to the old system while keeping the new one for read. If you didn't, you're doing a full reverse.
4. 4
   The partial rollback. Sometimes only one segment is broken. If you migrated by segment, you roll back that segment alone and leave the rest. This is the whole argument for segment-split migration.

Write each scenario with a named decision-maker, a threshold that triggers action, and the exact steps. The value isn't the document — it's that you've forced yourself to decide who pulls the trigger and at what number, before adrenaline is involved. If you already maintain solid runbooks and SLA discipline like the kind covered in this SLA-driven operations playbook for scaling tours, your migration rollbacks should slot into the same framework rather than being invented from scratch.

Training sprints: the part everyone under-plans

The data migration is usually fine. The people migration is what fails. Agents kept booking in the old system out of habit. A supervisor didn't know the new refund flow and improvised. Someone quoted an old price because they were looking at the old screen. Every one of those creates a data inconsistency that no amount of database validation catches, because the data is technically correct — it's just entered in the wrong place.

Don't train everyone at once in a single session two days before go-live. That knowledge evaporates. Run training in short sprints tied to the cutover phases:

1. 1
   Sprint 1 — Core booking flow, run 2–3 weeks out, in a sandbox with real-ish data. Just create-a-booking, take-a-payment, apply-a-discount.
2. 2
   Sprint 2 — Edge cases, run 1 week out

   refunds, group bookings, reschedules, the messy stuff that breaks when people improvise.

3. 3
   Sprint 3 — Cutover-day drill, run days before

   everyone does the exact sequence they'll do on launch day, including who to call when something looks wrong.

Assign each agent a competency check they have to pass before they touch live bookings on the new system. It feels bureaucratic. It also prevents the most common post-migration mess: weeks of subtly wrong data because half the team never really learned the new flow.

One more thing operators forget — your suppliers and resellers need a version of this too. If your OTAs are pushing bookings into a format your new system doesn't expect, that's a training and integration problem, not a bug.

RACI: who actually owns each piece

Migrations stall in the gaps between roles. The developer assumed ops was verifying the payment data. Ops assumed the developer was. Nobody was. A lightweight RACI prevents exactly this — not as corporate theater, but as a way to make sure every gate and every rollback trigger has a name attached.

The single most important cell in that table is who's Accountable for the rollback decision. It should be one person, and everyone should know who it is before go-live. Rollback decisions made by committee, in the moment, take too long — and in a booking system, every hour of hesitation is more orphaned data to clean up.

The runbook layer that keeps ops continuous

Underneath all of this is the boring, essential thing: written runbooks for the operational tasks that can't pause during cutover. Bookings still come in. Customers still call to change dates. Suppliers still confirm. Refunds still process. When your team is heads-down on the migration, these routine flows are exactly where continuity breaks.

1. 1
   Daily reconciliation — every day during the parallel run, someone confirms booking counts, payment totals, and upcoming departures match between systems. Not weekly. Daily. Divergence caught on day one is a fix; caught on day fourteen it's an investigation.
2. 2
   The "which system is source of truth right now" rule — written down, unambiguous, per segment. Ambiguity here is where double-bookings live.
3. 3
   Escalation paths — who to call when a booking looks wrong, a payment fails, a supplier confirmation doesn't sync.
4. 4
   Customer-facing scripts — what agents say when a customer references a booking the new system can't immediately find.

“

Automate daily reconciliation checks to catch divergence early and reduce manual investigation time.

If you've already built out a clean booking-to-settlement data flow — the kind described in this piece on why a minimum viable booking→settlement data stack fixes margin leakage — your migration reconciliation is dramatically easier. You already know what "correct" looks like at every stage, so you're comparing two systems against a known baseline instead of guessing.

This is also where AI-powered operational platforms do something genuinely useful. Automated reconciliation checks that flag divergence between old and new systems in near real time are far more reliable than someone eyeballing a spreadsheet at end of day. When you're running dual-write across tens of thousands of bookings, that kind of automated cross-checking is the difference between catching drift in hours versus discovering it after customers are already affected. The tooling doesn't replace the runbook — it just makes the runbook's most tedious, error-prone step something you can actually trust.

A real scenario: mid-size operator, mid-season

An adventure operator running roughly 14k–16k bookings a month needed to leave a legacy system that couldn't handle their new multi-day product logic. Their original plan was a weekend hard cutover in April, right as bookings were climbing toward summer. Wrong move.

They restructured it. Read-only shadow for two weeks first, which surfaced a commission-split calculation difference on agent bookings worth a few thousand a month if left unfixed. Then dual-write on single-day tours only — highest volume, lowest complexity — with daily reconciliation. Multi-day packages stayed on the old system for another three weeks until the new one had proven it could hold peak load.

Total elapsed migration time went from a planned two days to about six weeks. That sounds worse. It wasn't. Zero frozen sales windows, no customer-visible payment errors, and the one performance issue they hit during peak-hour testing got fixed before real customers ever touched it. The slower migration was the safer one, and it cost them nothing in bookings — which a botched weekend cutover almost certainly would have.

When a phased, gated migration makes sense — and when it doesn't

When it makes sense: you're above roughly 5k monthly bookings, you can't afford a sales freeze, you have open payment plans and future-dated departures in flight, and a wrong booking has real customer and financial cost. Basically every operator at real scale.

When it's overkill: you're genuinely small — a few hundred bookings a month, no complex deposit schedules, low future-dated volume. A gated six-week parallel run for 400 bookings is bureaucracy for its own sake. Freeze, migrate, verify, reopen.

Who should slow down before migrating at all: anyone trying to cut over during peak season. If you're heading into your busiest eight weeks, the answer is almost always "wait." The best migration is the one you do in your quiet season, with room to run parallel, gate properly, and roll back without adrenaline. Migrating into a peak is how good operators create their own worst month.

Bringing it together

A migration that keeps bookings running isn't about the new platform being great. It's about respecting how volume changes the rules.

Gate your phases with real pass/fail criteria. Run old and new systems together long enough to actually trust the new one. Plan rollback before you need it — including who pulls the trigger and at what threshold. Train your people in sprints instead of a single cram session. Put a name on every decision through a simple RACI.

Do those things and the platform switch becomes a non-event for your customers, which is exactly what it should be. They should never know it happened. The operators who pull that off aren't the ones with the fanciest new system — they're the ones who treated the cutover itself as an operation worth engineering, keyed to the one number that actually determines the risk: how many bookings are moving through their business while the ground shifts underneath.