Migration · Cloudbeds → Guest Talk · 10-14 days
Migrating from Cloudbeds to Guest Talk.
Cloudbeds to Guest Talk migrations are among the most common we run. Cloudbeds is a well-engineered platform and its export tools are cooperative, which means the technical part of the migration is straightforward. The real work is OTA re-certification (which is out of both platforms' direct control) and preparing your staff to switch operational muscle memory. This page walks through the plan we run for a typical 40-room independent.
Phase 1 — export and dry run (days 1-3)
Day 1. Kickoff call. We confirm the target go-live date, the parallel-run window, and the peak-off-season timing. If you are in peak, we push go-live to the first Monday of your low season.
Day 2. You run the Cloudbeds full-account export (Settings > Data Export). Guest Talk's migration engineer ingests the export into a dry-run workspace within 24 hours.
Day 3. We share the dry-run workspace with you for review. You verify room types, rate plans, sample reservations, guest profiles and folios. Corrections (naming, room mapping, custom fields) are noted here and applied in the real migration.
Phase 2 — parallel setup (days 4-8)
Day 4. Guest Talk configures the production workspace with the corrected mappings. Front-office training runs (90 minutes).
Day 5. Housekeeping training (60 minutes) and accounting training (60 minutes) run in parallel.
Day 6. Booking.com and Expedia re-certification requests are submitted with the new Guest Talk partner code. Typical certification is 3-5 working days.
Day 7. Payment processor connection. If you were using Cloudbeds Payments, you now connect Stripe (or your preferred processor) to Guest Talk; if you were on your own Stripe already, we migrate the customer objects and existing card references.
Day 8. Direct-booking widget replaced on your website. Cloudbeds widget removed; Guest Talk widget deployed. If you have a bespoke web design, this is where the design partner styles the new widget to match.
Phase 3 — cutover (days 9-11)
Day 9 (Friday). Final data delta export from Cloudbeds. Any bookings created since Day 2 are appended to the Guest Talk workspace. Cloudbeds channel connections are paused (rate and inventory writes off).
Day 10 (Saturday, low activity). Guest Talk channel manager takes over. First 24 hours are observed by our channel team plus your revenue manager. Any parity break is caught within an hour by the parity monitor.
Day 11 (Sunday). Guest Talk is fully live. Cloudbeds is set to read-only for staff reference; new reservations flow entirely through Guest Talk.
Phase 4 — stabilise and decommission (days 12-14)
Day 12 (Monday). First full working day live. Onboarding manager on standby for the day; morning check-in call and evening close-out call.
Day 13. Review the first weekend's reports. Compare against Cloudbeds' last full week to spot any material metric divergence (usually there is none; small differences are attributable to the different calculation windows).
Day 14 (Wednesday). Cloudbeds subscription cancelled. Historical export retained by Guest Talk in cold storage on your behalf for compliance access. Old widget URLs redirected.
Common gotchas
OTA reservation aliases. Cloudbeds and Guest Talk both use OTA-provided aliases as guest email; the alias format is identical, so past-reservation emails continue to work. Occasionally an OTA rotates the alias; we detect this and re-request current addresses at the OTA.
Custom fields. Cloudbeds' custom field mechanism differs slightly from Guest Talk's; the migration engineer maps each custom field and, where semantics differ, documents the mapping in the workspace so staff know where a specific value ended up.
Payment references. Stripe customer IDs and payment method IDs are portable if you keep the same Stripe account; if you move Stripe accounts, historical cards on file are not usable and you must ask guests to re-enter card details on next stay. We plan Stripe account continuity into the migration where possible.
Booking.com "Preferred Property" status. Changing channel manager does not change Booking's Preferred Property rating; it changes ownership of the connection metadata only. Your ranking is unaffected.
Data mapping reference
- Reservations — imported with full history including modifications and cancellations.
- Guests — imported with contact details, marketing consent status, tags and notes.
- Room types and units — one-to-one map; renames applied.
- Rate plans — base rates as base plans in Guest Talk; derived rates as derivations.
- Folios and payments — imported with immutable references; new folios open in Guest Talk after cutover.
- Housekeeping status — current-day snapshot imported; historical status not migrated (Guest Talk generates history from the day it is live).
- Reports — historical revenue reports available in the Cloudbeds export retained by Guest Talk in cold storage; Guest Talk begins to generate its own reports from cutover.
What can go wrong (and what we do about it)
Booking.com certification stalls. The channel manager change requires Booking's Connectivity team to re-run certification against Guest Talk's partner code. Occasionally certification stalls due to rate-plan mismatches; we handle the ticket back and forth with Booking on your behalf.
Cloudbeds export incomplete. Very rarely, Cloudbeds' export omits a field or a small set of records due to a transient issue. We ask you to re-export; when the re-export also fails we contact Cloudbeds Support jointly.
Staff resistance. A subset of staff invariably finds any migration stressful. The onboarding manager stays on standby for the first week and runs an extra thirty-minute Q&A whenever needed; we have never had a Cloudbeds migration where staff remained uncomfortable past day 14.
Getting the migration started
Email hello@talkg.fabriza.org with your Cloudbeds property URL and your preferred go-live date. We reply within one business day with a firm quote and a proposed kickoff date.