Moving from Mews to Sabee.

Where the data models diverge

Mews structures its inventory as spaces belonging to space categories, with products (breakfast, parking, spa credits) sold as line items against a bill that may be shared across reservations. Sabee structures its inventory as rooms belonging to room types, with extras and packages that attach at the reservation level. The two models are close but not identical: a Mews space category maps cleanly onto a Sabee room type; a Mews space maps to a Sabee room; but Mews products need explicit mapping to Sabee extras or, where the product is really a rate package, to a Sabee rate plan.

The mapping decision for each Mews product is made during scoping in week 1 and documented in the mapping report. A rule of thumb: a product that is a physical or service add-on with its own inventory (breakfast covers per day, parking spots per night) becomes a Sabee extra; a product that is really a marketing bundle of room-rate plus add-ons (a "romantic weekend package" combining room, breakfast and a bottle of wine) becomes a Sabee rate plan with the add-ons pre-attached.

The data map, field by field

Mews field	Sabee field	Notes
Space category	Room type	Preserved 1:1
Space	Room	Preserved with the Mews space name as the room number
Reservation	Reservation	External ref preserved as external_ref
Customer (owner)	Guest profile	Deduplicated on email at import
Customer (companion)	Guest profile (secondary)	Preserved as additional guest on the reservation
Rate	Rate plan	Base rate preserved; derived rates preserved as separate plans
Rate group	Rate plan group	Preserved
Restrictions	Restrictions (MinLOS, MaxLOS, CTA, CTD, Stop Sell)	Preserved 1:1
Product (add-on)	Extra	Individual mapping confirmed in scoping
Product (package)	Rate plan with attached extras	Package construction rebuilt in Sabee before cutover
Bill	Folio	Bills split across reservations rebuilt as folios per reservation
Payment	Payment	Payment records preserved with original date and method
Deposit request	Deposit request	Outstanding deposits carried into Sabee for continued collection
Accounting export	Invoice export	Sabee produces an equivalent export in the customer's accounting system's format
Users and roles	Users and role templates	Role scopes mapped and permission audit scheduled in week 4
Distribution channels (BDC, Expedia, etc.)	Channel mapping	Preserved; reconnected at cutover

The five-week plan

Week 1: scoping

A kick-off call with the property's ops lead, revenue lead, and finance contact. Mews API access is provided under a scoped connector role for the Sabee onboarding team to pull a first tenant snapshot. The scoping call confirms the cutover window (typically a Sunday night to Monday early morning), the list of channel reconnections, the products-to-extras/rate-plans mapping decisions, and the training schedule.

Week 2: rehearsal migration

Full Mews snapshot loaded into a Sabee sandbox tenant. The onboarding team runs the standard data map, produces a mapping report highlighting every product decision from scoping, and hands it to the customer for review. Any mapping issue — a rate group that didn't resolve cleanly, a product whose classification wasn't obvious in scoping — is corrected in the mapping definition before the live cutover.

Week 3: training and integration prep

Reception, reservations and revenue teams train on Sabee using the sandbox tenant as the practice environment. Housekeeping training happens on-property once the sandbox is loaded. Channel-manager credentials and any third-party integration credentials (payment provider, booking widget, guest-messaging integration) are prepared for cutover reconnect.

Week 4: staff training completion and final rehearsal

A final rehearsal migration uses a fresh Mews snapshot from the day before to catch any changes since the week-2 rehearsal. Reception and reservations complete their training with a Q&A on-property, and the operations lead signs off on the mapping report as the final version to be used at cutover.

Cutover weekend

Mews is placed in read-only mode at the agreed cutover start. A final delta snapshot is pulled, loaded into Sabee production, and the channel-manager connections are reconnected outward from Sabee. Front desk uses a printed arrivals list from Mews for any check-ins that fall inside the window, entering them into Sabee the following morning. Cutover typically runs 4 to 8 hours end-to-end.

Weeks 5 and 6: validation

Sabee reports run in parallel with Mews (which remains read-only) for two weeks, and finance reconciles the numbers daily. At the end of the validation period the customer signs off and the Mews tenant is decommissioned.

Downtime window

Total downtime is typically 4 to 8 hours, all inside the pre-agreed cutover window. During cutover, reception uses printed arrivals from Mews for any check-ins inside the window and enters them into Sabee on the following morning shift. Guest-facing systems (booking widget, direct-booking flow) can be switched to Sabee once cutover completes; a 24-hour safety margin with the booking widget still pointed at Mews is a common choice for extra caution.

Rate strategy handover

The rate strategy comes across as-is. Because Mews's rate model and Sabee's rate model use slightly different derivations for adjusted rates (Mews derives via rate groups; Sabee derives via rate-plan modifiers), the rate rehearsal in week 2 explicitly confirms that the derived rates land at identical values in the Sabee sandbox as they show in Mews. Any drift is corrected in the mapping before cutover, so the first Sabee-issued rate ping to Booking.com after cutover matches the last Mews-issued rate ping before it.

Product library handover

Mews's product library is the area where migrations from Mews most often surface decisions rather than problems. A property that has accumulated forty or fifty products over several years typically finds that the migration is a good moment to consolidate: several products with near-identical descriptions get merged, a handful of products that were never actually sold get retired, and the remainder land in Sabee as a smaller, cleaner set of extras and rate-plan packages. The mapping report in week 2 highlights every product with zero sales in the last 12 months as a candidate for retirement rather than migration.

Staff training

Training covers reception, reservations, revenue and housekeeping across two on-site days in week 3, followed by a Q&A on-property in week 4. The single biggest workflow change for teams coming from Mews is the folio model: Sabee attaches folios to reservations rather than to bills that can be split across multiple reservations, and the folio-split workflow in Sabee is deliberately explicit rather than implicit. Reception training spends extra time on this specific difference so the first live shift on Sabee doesn't hit the change unprepared.

Automation and API-driven workflows

Properties that leaned heavily on Mews' open API and automation engine to build bespoke workflows — a custom pre-arrival messaging sequence, a rate change triggered by an external demand-forecasting tool, a housekeeping assignment rule tied to a specific staffing app — need a dedicated review during scoping rather than a simple field-by-field mapping, because these workflows often live partly outside Mews itself in a connected script or third-party app. Our migration specialist catalogues every such workflow during week 1, identifies which ones map onto a native Sabee feature (yield rules, no-show automation, pre-built pre-arrival email flows), and which ones will need to be rebuilt against the Sabee API and webhooks after cutover. Because Sabee exposes its own REST API and webhook events (see the API reference and webhooks documentation), most custom Mews workflows have a reasonably direct path to a Sabee-native equivalent, though the rebuild typically happens in the weeks following cutover rather than being a blocking dependency for go-live.

Multi-property Mews accounts

Mews groups running several properties under one enterprise tenant go through an additional consolidation step during scoping. Because Mews' multi-property structure and Sabee's Multi-property module organise permissions and central rate strategy differently, the migration plan documents how each property's existing staff permissions map onto Sabee's per-property and group-level role templates, and whether the group wants to standardise product and rate-plan naming across properties as part of the move or preserve each property's existing conventions. As with any multi-property migration, properties are cut over one at a time rather than simultaneously, both to limit operational risk and to let lessons from the first cutover inform the rest of the rollout.

Common questions during a Mews migration

The most frequent scoping-call question is what happens to a Mews product with no clean Sabee equivalent — usually a bespoke package built around a very specific local partnership (a spa credit shared with a neighbouring wellness centre, for example). These are handled case by case: some are rebuilt as a Sabee extra with a manually-tracked redemption process, and others are flagged as a genuine gap to be raised with the Sabee product team as a feature request. The second most common question concerns payment continuity — stored card tokens for future reservations generally carry over cleanly where the underlying processor (Stripe or Adyen) supports token portability, and guests are only asked to re-enter card details in the rare case where a legacy processor integration doesn't support it.