Migration playbooks, per source system.
Migrating to Talk with Guest is not a marketing headline. Every property has a specific current-state stack, a specific set of OTAs, a specific factura sequence and a specific WhatsApp number. These playbooks describe the migration honestly — timing, data mapping, gotchas, sign-offs — so that a general manager can plan the switch around running the property.
The five days that decide the outcome
Regardless of source system, every Talkguest migration is anchored on the same five events. First, the kick-off call with the migration engineer and the general manager on day one, where the current-state stack is documented and the target-state configuration is decided. Second, the data-export day, where guest profiles, historic reservations, OTA mappings and factura sequences are pulled from the source system. Third, the parallel-run window, when Talkguest is provisioned and populated in parallel to the live system so the two can be cross-checked reservation by reservation. Fourth, the channel-manager cutover, a single afternoon window in a low-occupancy midweek slot when Booking, Expedia, Airbnb and any other OTAs are re-pointed from the old master to Talkguest. Fifth, the go-live day, when the old system is switched to read-only and Talkguest becomes the master of record for every reservation, guest, factura and WhatsApp conversation.
Everything else in the playbooks below is source-system-specific. The five events above happen in every migration, and the migration engineer is present on every one.
Pick your source system
From Cloudbeds
Two-week playbook for a boutique or small group moving off Cloudbeds — data mapping, channel-manager cutover, WhatsApp cutover, factura sequence continuity.
From Mews
Two- to three-week playbook for a boutique moving off Mews to a leaner platform. Marketplace app inventory, room-type consolidation, deposit continuity.
From a legacy or on-premise PMS
Three- to four-week playbook for properties on Opera, Protel, Amadeus or a custom on-premise system. Data extraction, on-premise decommissioning, network cutover.
A named person, not a ticketing queue
Every Talkguest migration is run by a named migration engineer who is assigned to your property from day one to go-live plus fourteen days. That engineer sits between your general manager and Talkguest's engineering team; they are the single point of contact for the migration and they carry the plan, the timing and the sign-offs. This is included in the platform price — there is no separate professional-services line for migration.
What the migration engineer runs, week by week: in week one they document the current-state stack, verify the data-export path from the source system, provision the Talkguest tenant, load the guest CRM, configure the VAT profiles, and align factura sequences. In week two they run the parallel window, cross-check every reservation between the two systems, resolve the discrepancies, prepare the channel-manager cutover script and rehearse the WhatsApp cutover. On go-live day they are on the property or on a permanent Zoom bridge from the morning of the cutover until end-of-day.
Post-go-live, the same engineer stays available for fourteen days to catch the operational edge cases the migration itself did not surface — a Booking.com virtual-card that maps to a rate plan that does not exist, a Portuguese-language pre-arrival template that needs a small edit, a factura that a Portuguese accountant queries. Only after those fourteen days does the account transition to the standard support queue.
Why AT registration does not need to be re-done
The single most-asked question at migration kick-off is what happens to the property's Autoridade Tributária factura sequence. The answer is: nothing. The AT-registered series belongs to the property, not to the platform. When a property switches from a source system to Talkguest, the certified series simply continues on Talkguest — the next factura issued after go-live picks up the next number in the same series. There is no interaction required with the AT, no new registration, no gap in the numbering.
Historic facturas from the previous system are imported into Talkguest as an audit trail. They are searchable, linked to the guest profile, exportable as PDFs, and included in the property's document archive for the statutory retention period. The monthly SAF-T (PT) file that Talkguest produces from the go-live month onwards contains only new facturas issued on the platform; the source-system's file for the pre-migration months remains authoritative for that period.
What comes across and what doesn't
What comes across is the operational reality of the property. Guest profiles with contact details, preferences, allergies, VIP flags, historic stays and lifetime value. Upcoming reservations with rate plans, room assignments, deposit status, folio balances and any attached documents. Historic reservations for the previous 24 months, kept for guest-history purposes. OTA mappings — Booking property ID, Expedia property ID, Airbnb listing IDs — with their rate-plan mappings intact so the channel-manager cutover is a switch rather than a rebuild. Factura sequences and the associated VAT profiles. Housekeeping room codes and schedules.
What gets to be left behind is the archaeological layers of the old system. Deprecated rate plans nobody uses any more. Guest tags added by a receptionist who left in 2019. Reports built for a manager who no longer works there. The migration engineer helps the general manager decide what to bring and what to archive — most properties come out of migration with a cleaner data model than they had going in, which is one of the accidental benefits.
The archive itself is real, not marketing language. Data left behind is written to a read-only archive at Talkguest's Frankfurt data centre, exportable at any time as CSV or SAF-T (PT) files, and retained for the statutory period the property's jurisdiction requires. Nothing is thrown away — the general manager chooses what to bring into the live system and what to keep behind glass. If a receptionist a year later needs to look up a guest tag from 2019 for a returning-guest recognition, the archive answers the query in a search box; the guest tag simply is not part of the day-to-day operational database any more.