Moving from Cloudbeds to Sabee.

What migrates and what doesn't

The Cloudbeds data model and Sabee's are close enough that the great majority of the data comes across cleanly. Reservations (past, present and future), guest profiles, room types and room-numbering conventions, rate plans and derived rates, availability calendars, folios and their line items, invoices already issued, deposit records, housekeeping status history, and channel-mapping identifiers (Booking.com property id, Expedia HCID, Airbnb listing ids) all migrate one-to-one. Historical revenue records — check-out totals, extras, room-service items — come across in full so year-on-year reporting in Sabee's Revenue Analytics module is possible from the first day on the new system.

Two categories don't migrate directly and need handling in a scoping call: custom fields the property has added to guest or reservation records, which are mapped case-by-case to Sabee's own custom-field feature or into free-text notes if no structured equivalent exists; and any Cloudbeds Marketplace apps that write data into the tenant — some of these have Sabee-native equivalents, some don't, and the migration plan documents the decision for each app before cutover so no in-flight workflow depends on an app that isn't coming across.

The data map, field by field

Below is the standard Cloudbeds-to-Sabee data map applied by default. Every field is confirmed with the customer during scoping and can be overridden per property if the customer's Cloudbeds setup diverges from Cloudbeds' own defaults.

Cloudbeds field	Sabee field	Notes
Reservation ID	Reservation ID (external_ref)	Cloudbeds ID preserved as external reference; Sabee assigns its own primary key
Guest first / last / email	Guest profile fields	Deduplicated on email at import
Guest date of birth	Guest profile DOB	Preserved where present; not required
Room type	Room type	Names preserved; Sabee re-slugs to lower-case for the API
Room number	Room number	Preserved exactly
Rate plan	Rate plan	Non-refundable and refundable variants preserved as separate plans
Nightly rates	Rate cells	Full historical rate calendar imported so revenue analytics can back-report
Availability restrictions	Restrictions (MinLOS, MaxLOS, CTA, CTD, Stop Sell)	Preserved 1:1
Folio line items	Folio line items	Tax breakdown recomputed against the property's Sabee tax configuration
Deposit records	Deposit ledger	Preserved with original charge date
Invoices issued	Invoices (read-only)	Historical invoices come across read-only for audit; new invoices issue from Sabee going forward
Housekeeping status	Housekeeping status	Current state imported; historical logs preserved as notes on the room record
Booking.com property ID	Channel mapping (BDC)	Preserved; channel manager reconnect happens during cutover
Expedia HCID	Channel mapping (Expedia)	Preserved
Airbnb listing IDs	Channel mapping (Airbnb)	Preserved per unit
Guest notes	Guest profile notes	Free-text preserved; internal-only visibility preserved
User accounts / roles	Users / role templates	Roles mapped to Sabee equivalents; permission audit scheduled in week 4

The five-week plan

Week 1: scoping

A kick-off call with the property's operations lead, the person responsible for revenue strategy, and — if the property is part of a group — the group operations director. Cloudbeds export access is provided to the Sabee onboarding team under a scoped export role, and a first snapshot of the tenant is pulled for the data-map review. The scoping call also confirms the target cutover window (typically a Sunday night to Monday morning, at the property's lowest-traffic slot), the list of channel manager connections that will need reconnecting during cutover, and the training schedule for reception and housekeeping staff in weeks 3 and 4.

Week 2: rehearsal migration

A full Cloudbeds export is loaded into a Sabee sandbox workspace with a copy of the property's current tenant configuration. The onboarding team runs the standard data map, produces a mapping report showing every field that landed cleanly and every field that requires a decision, and hands the report to the customer for review. Any mapping issue found in the rehearsal is corrected in the mapping definition before the live cutover, so the live migration is not the first time the customer sees the result.

Week 3: training and integration prep

Reception, housekeeping and reservations staff are trained on the Sabee workflow — either at the property or remotely — using the sandbox tenant from week 2 as the practice environment. The trainer works through the day-in-the-life workflow (arrivals, check-in, room assignment, folio adjustment, check-out) rather than a feature tour. In parallel, channel manager credentials are prepared for the reconnect during cutover, and any third-party integration that will continue to use the tenant (booking widget, payment provider) is configured against a test key so it can be switched to the live key at cutover.

Week 4: staff training completion and final rehearsal

A final rehearsal migration is run at the end of week 4 using a fresh Cloudbeds export from the day before, so any changes to the source tenant during weeks 2 and 3 are reflected. The output is diffed against the week-2 rehearsal to confirm the mapping is stable and no new issues have surfaced. Staff training is completed with a final Q&A session at the property, and any workflow decisions still outstanding (folio-adjustment procedure, refund-authority thresholds, housekeeping-status flow) are documented in the property's own operational handbook to survive staff turnover.

Cutover weekend

Cloudbeds is placed into read-only mode at the agreed cutover start (typically Sunday 22:00 local time). A final delta export is pulled, loaded into the Sabee production tenant, and the channel manager connections are re-established from Sabee outward to Booking.com, Expedia and Airbnb — a process that typically takes 60 to 90 minutes across all three, during which those channels temporarily stop syncing new bookings but existing bookings remain reflected on both sides. By the agreed cutover end (typically Monday 04:00 local time), the Sabee tenant is live, channels are reconnected, and reception is signed in on the new dashboard for the morning shift. The old Cloudbeds tenant remains read-only for the two-week validation period so any historical query can still be answered against the original source.

Weeks 5 and 6: validation

For two weeks after cutover, Sabee's Revenue Analytics reports and Cloudbeds' own reports are pulled daily and compared line-by-line by the group finance function. Any discrepancy — a folio total that differs, a channel commission that reconciles to a different amount — is escalated to the Sabee onboarding team the same day and resolved before the validation period ends. At the end of the validation period, the customer signs off on the migration and the old Cloudbeds tenant is decommissioned.

Downtime window

Total downtime on the Sabee migration is typically 4 to 8 hours, all inside the pre-agreed cutover window. During cutover, the property front desk uses a printed arrivals list from Cloudbeds for any check-ins that happen inside the window, and enters them into Sabee on the following morning. Guest-facing systems (booking widget, direct-booking page) can be switched to Sabee as soon as cutover completes, but the property may choose to leave the booking widget pointed at Cloudbeds for an additional 24 hours as a safety margin.

Rate strategy handover

Cloudbeds' rate strategy (BAR levels, seasonal rules, minimum-stay rules) comes across as-is, but it is worth using the migration as an opportunity to review it rather than replicate it blindly. During week 3, the Sabee onboarding team offers an optional rate-strategy review session with the customer's revenue lead, covering: whether the current BAR ladder still matches demand a season later; whether channel-parity rules are enforced consistently across all channels or drifting between them; and whether any minimum-stay rules from a previous season should be relaxed or tightened for the coming quarter. See rate parity and price strategy for the framework.

Staff training

The training programme covers reception (arrivals, check-in, folio, check-out, adjustments), housekeeping (room-status updates, room notes, mobile workflow — see housekeeping mobile workflow), reservations (new bookings, modifications, cancellations, deposit handling) and revenue (rate updates, restriction management, group booking builder). The four modules are typically delivered across two on-site days in week 3, followed by a Q&A session in week 4 once staff have had a week to practice in the sandbox.

Multi-property Cloudbeds accounts

Groups running several properties on Cloudbeds — often each on its own tenant, sometimes with inconsistent rate-plan naming and role structures built up over years — go through an additional consolidation step before the five-week plan begins. A group-level scoping call maps each property's tenant separately, but the mapping report also flags naming inconsistencies across properties (a "Superior Double" in one tenant and a "Deluxe Double" in another that are functionally the same room category) so the group can decide whether to standardise naming as part of the move or preserve each property's own conventions inside Sabee's Multi-property module. Migrating a group is almost always sequenced one property at a time rather than a single simultaneous cutover across the whole portfolio, both to limit risk and to let the operations team apply lessons from the first property's cutover to the rest.

Common questions during a Cloudbeds migration

Two questions come up in nearly every scoping call. The first is whether historical guest reviews or ratings synced through Cloudbeds carry over — they don't, since review data belongs to the OTA or review platform itself rather than the PMS, and reconnecting the channel after cutover automatically restores the same review visibility on Booking.com, Expedia and Airbnb regardless of which PMS is behind the connection. The second is what happens to reservations that span the cutover date itself — a guest checked in on Cloudbeds before cutover who is still in-house afterward. These stays are imported as active reservations with their original check-in date and folio history intact, so the guest's check-out on Sabee reflects the full stay rather than starting a new folio at cutover.

A third, less common but important question concerns payment processor continuity. If your Cloudbeds account uses a payment processor integration for card capture, that connection is reconfigured against Sabee during week 3 rather than at cutover itself, using a test transaction to confirm captures and refunds route correctly before any real guest payment depends on it. Stored card tokens for future reservations (an upcoming guest's deposit, for example) are preserved through the migration wherever the processor supports token portability, which Stripe and Adyen both do; a small number of legacy processor integrations do not support this, in which case affected guests are asked to re-enter card details at check-in rather than losing the reservation.