Migrating from a legacy on-premise PMS — the on-property switch.
This is the playbook the Talkguest migration team runs when a Portuguese property moves off an on-premise system — Oracle Opera, Protel Air's on-prem instances, Amadeus PMS, or a custom Windows application running on a desktop behind reception. Twenty-one to twenty-eight working days, one migration engineer, one on-property visit, and a physical retirement of the old server.
The shape of the property, the shape of the system, the shape of the migration
This playbook is written for a Portuguese property still on an on-premise PMS in 2026. The typical set-up is a Windows-based application from Oracle Opera, Protel, Amadeus or a boutique local vendor, installed on a desktop or a small server behind the reception counter, with a printer wired directly to the certified factura sequence, a separate channel manager licensed by month, and a WhatsApp workflow that lives on a receptionist's personal phone. The estate is stable, the property knows it, and the switch is a real project — not a Saturday-afternoon subscription swap.
Because the system runs on-property, the migration includes an on-property visit by the migration engineer during cutover week. This is included in the platform price — there is no travel line billed. The visit is typically two full days: one to run the data-export session and one to be physically present for go-live. The physical server or desktop is not touched until forty-eight hours after go-live, at which point it is powered down, archived to a read-only virtual machine at Talkguest's data centre, and the physical hardware is either handed back to the property or, if the property prefers, removed and recycled by a certified vendor.
Four weeks, in order
- Week 1, day 1 — Kick-off, remote. Migration engineer, general manager, accountant, and if possible the IT contractor who maintains the on-premise system. Current-state stack documented: PMS vendor and version, database engine, on-premise integrations (payment terminal, key-card system, phone-billing pass-through, POS), factura sequence, VAT profiles, WhatsApp arrangement.
- Week 1, day 2 — Remote database access set up. The migration engineer establishes a read-only remote connection to the on-premise database, typically over a VPN with two-factor authentication or an SSH tunnel to a jump host. If the on-premise system does not permit remote access, day 2 slips to the on-property visit in week three and the timing extends.
- Week 1, day 3 — Data schema review. The legacy system's data model is documented — table names, key relationships, custom fields the property has added over the years. This is the day that turns a legacy migration from art into engineering.
- Week 1, day 4 — Talkguest tenant provisioned. Property record created, users invited, rooms and room types mapped, VAT profiles configured, factura series carried from AT registration.
- Week 1, day 5 — Historic data extraction, dry run. A full read of the historic guest CRM and 24-month reservation history is pulled from the legacy database and loaded into Talkguest as a staging dataset. Data quality issues surfaced.
- Week 2, day 6 — Data cleaning pass. Guest profiles de-duplicated, guest tags normalised, rate plans cleaned up. Migration engineer and general manager work through the discrepancy list one row at a time.
- Week 2, day 7 — Reservation load, historic. The cleaned historic reservations loaded into Talkguest read-only.
- Week 2, day 8 — Reservation load, upcoming. Every upcoming reservation loaded and cross-checked against the legacy system.
- Week 2, day 9 — OTA re-mapping. Booking, Expedia, Airbnb and any other active OTAs re-mapped in Talkguest's channel manager. If the property is on an external channel manager, the property's OTA property IDs are moved to Talkguest.
- Week 2, day 10 — WhatsApp setup. WhatsApp Business API provisioned or ported. Templates loaded end-to-end tested.
- Week 3, day 11 — Cross-check pass one. Every reservation, every folio, every deposit verified.
- Week 3, day 12 — Migration engineer on property. Physical visit to the property. Payment terminal, key-card system, phone-billing pass-through and POS integrations tested end-to-end against Talkguest.
- Week 3, day 13 — Cross-check pass two, on property. Every upcoming reservation, every deposit, every open folio walked through with the reception team. Final go/no-go decision at end of day.
- Week 3, day 14 — Channel-manager cutover, afternoon. OTAs switched from the legacy channel manager to Talkguest. Test booking placed and traced.
- Week 3, day 15 — Go-live, morning. Talkguest becomes master of record. Legacy system moves to read-only. Migration engineer physically on the property from morning through end of day.
- Week 4, day 16 to 20 — First week live. Reception, housekeeping and reservations run entirely on Talkguest. Migration engineer on-call remotely.
- Week 4, day 21 — Legacy server retirement. The on-premise server or desktop is powered down. Data is archived to a read-only VM at Talkguest's data centre for the statutory retention period. The physical hardware is either handed back or recycled by a certified vendor.
Four things that are unique to on-premise migrations
The database schema is undocumented. Legacy systems typically ship with a documented core schema and years of ad-hoc additions on top. Custom fields, ad-hoc tables, and stored procedures the property added over the years are usually not documented. The day-3 schema review takes longer for a legacy source than for a cloud source, and the migration engineer sometimes finds himself reverse-engineering a stored procedure to understand what a field actually represents.
The payment terminal is wired to a specific PSP. On-premise PMSs are frequently coupled to a specific payment terminal and a specific PSP through a physical wire or a serial connection. Cutover to Talkguest means moving payments to the property's PSP account through Talkguest's PSP integration. The day-12 on-property visit is the moment this transition is tested end-to-end with real cards.
Factura printer configuration. Portuguese hotels running on-premise systems often have a factura printer wired directly to the PMS with the AT-registered series stored in the printer's memory. During cutover the printer is either re-configured to accept factura output from Talkguest, or retired in favour of Talkguest's PDF-and-email factura workflow. Either way is fine — the property decides at day 3.
Key-card system integration. Boutique hotels frequently run a key-card system tightly coupled to the on-premise PMS. Talkguest supports the major key-card vendors (Assa Abloy, Salto, Onity, Dormakaba) through direct integrations. During the on-property visit the migration engineer verifies that check-in on Talkguest triggers key encoding on the property's existing key-card system.
The two weeks after the server goes off
The migration engineer stays on the account remotely for fourteen working days after go-live and returns to the property for a half-day at day 30 to run a physical review with the reception team and the accountant. During the post-go-live window the typical surprises are practical rather than technical — a receptionist who has been using the legacy system for eight years takes a week to adjust to a new interface; the housekeeping supervisor discovers that the mobile app is easier than the printed round; the accountant queries a SAF-T (PT) line and needs a walk-through of the export.
At day 30 the migration engineer runs the final walk-through, hands the account to Talkguest's standard support queue, and the property is fully self-sufficient. See the Solar do Chiado case study for a real legacy migration, and the pricing page for what running Talkguest costs after go-live. Ready to start? Head to get access.