Moving from a legacy on-premises PMS to Sabee.

Why on-prem migrations are different

The characteristics that make on-premises PMS migrations distinctive are consistent across systems and vendors: no first-party export tool, so data is either extracted by direct database access (SQL Server or MDB) or by scripted UI-driven exports; historical data spread across multiple database files if the property has been through prior version upgrades; a Windows-only front-desk workflow that staff have known unchanged for years, which raises the training cost of a switch even when the software itself is worse; and a physical dependency on a specific machine at the property, which means downtime during cutover has to be planned around the fact that even reading the source data requires access to that machine.

Sabee has run migrations from a range of older regional systems: Protel Air (pre-cloud versions), Fidelio 8, Opera on-prem, Micros property editions, Hetras before its cloud transition, and a long tail of smaller regional systems used mainly in Southern Europe and the Balkans. The plan below is written for the general case; specifics vary by source system and are documented in the scoping call.

Data extraction: the biggest phase

Where a cloud-to-cloud migration spends a day or two on data extraction, an on-prem migration typically spends two to three weeks. The extraction happens in three passes: a first pass by database dump — where the source system's underlying database (SQL Server, MDB or, in some older systems, a proprietary flat-file format) is dumped in full, taken off-site and parsed into a normalised staging schema; a second pass to fill gaps that the first pass couldn't reach — often historical data from before a version upgrade that sits in a legacy database rather than the current one, or PDF-only invoices that never made it back into structured records; and a third pass to reconcile the first two into a single canonical dataset for the migration.

Practically, this means the Sabee onboarding team needs remote or on-site access to the source-system machine for the first phase, and a scoping call is scheduled specifically to agree how that access will be arranged (a temporary VPN, a read-only account on the local database, a physically attended session where a Sabee engineer joins the property IT contact by remote screen-share for a limited window).

The data map, adapted for on-prem

The six-to-eight week plan

Weeks 1 and 2: scoping and data extraction agreement

Kick-off call with the property's operations lead, an IT contact (typically the person who has historically maintained the front-desk machine and the source-system installation), and the property owner. The scoping call agrees the access arrangement for the source-system machine, the target cutover window, and the ambition for historical data: how many years of history to bring across (typically the last 24 months of transactional data is the minimum, with anything older imported as archived reference data if it exists in structured form).

Weeks 3 and 4: data extraction and staging

The Sabee onboarding team runs the extraction passes described above, working with the property's IT contact for source-system access. Extraction is done to an offline staging environment maintained by Sabee, never directly into the customer's production Sabee tenant. At the end of week 4, a data extraction report is delivered to the customer showing what was extracted, what could not be extracted (with reasons), and any decisions still outstanding.

Week 5: rehearsal migration and mapping review

Staged data is loaded into a Sabee sandbox tenant with the customer's target configuration. A rehearsal-mapping report is produced and reviewed with the customer, with particular attention to how legacy rate rules unroll into the historical rate calendar, how legacy free-text extras normalise into the Sabee extras list, and how PDF-only historical invoices are attached to the corresponding reservations.

Week 6: staff training

Training is more intensive than a cloud-to-cloud migration because staff are switching not just software but a whole interaction model: from a Windows-native front-desk workflow they have known for years, to a browser-native workflow with different keyboard shortcuts, a different room-status flow and a different folio-adjustment paradigm. Sabee's onboarding team typically spends two full days on-property in week 6, with follow-up remote sessions in week 7 as the sandbox is used for realistic practice.

Week 7: final rehearsal and channel manager prep

A second rehearsal migration uses a fresh source-system snapshot to catch any changes since the week-5 rehearsal. Where the property is adopting a channel manager for the first time as part of the switch to Sabee — a common pattern when moving off legacy on-prem systems that predate meaningful channel-manager integration — channel manager credentials are set up and tested against Booking.com and Expedia in a staging configuration ready for cutover.

Week 8: cutover and validation

Cutover for an on-prem migration typically runs longer than a cloud-to-cloud cutover, because the final delta extract from the source system has to happen against a local machine rather than a cloud API. A 12 to 16 hour window is common, planned around the property's lowest-traffic overnight slot. Reception uses printed arrivals from the source system for any check-ins inside the window. Validation runs for two weeks after cutover with the source system kept powered on and read-only for reference queries.

Downtime window

The extended cutover window (12–16 hours vs. 4–8 for cloud-to-cloud) reflects the reality that reading a final delta out of a local database is slower and more manual than pulling a delta export from a cloud API. Reception at the property uses printed arrivals and a paper folio process for any check-ins that fall inside the cutover window, entering them into Sabee on the following morning. Channel managers, if newly connected as part of the switch, are reconnected outward from Sabee during the cutover so that inventory continues to reach OTAs on the following morning.

Historical data trade-offs

How much history to migrate is a decision the property makes during scoping, and there is no right answer that fits every property. Bringing across 24 months of transactional history is the typical baseline — enough for year-on-year reporting to work correctly from day one on Sabee. Older data can be brought across as reference records where it exists in structured form, or kept archived in the original system's format if it doesn't. Some properties choose to bring only the last 12 months and keep everything older on an offline archive; some choose to bring everything they have; both are valid choices and the trade-off is between extraction effort and depth of long-term reporting.

Staff training

The single largest workflow change from a legacy on-prem PMS is the shift from a keyboard-driven Windows workflow to a browser-driven workflow with different interaction patterns. Sabee's on-property training in week 6 spends deliberate time on the workflows staff use every hour of every shift — arrivals, check-in, room assignment, folio, adjustments, check-out — and rehearses them against a realistic sandbox until each is fluent, rather than doing a feature tour. Housekeeping training additionally covers the mobile workflow (see housekeeping mobile workflow), which is often a net-new capability for properties coming off older on-prem systems that never had a housekeeping mobile app.

Manual reconciliation checklist

Because on-prem extraction relies on database dumps and scripted exports rather than a clean vendor API, we ask every customer's finance and front-desk lead to work through a manual reconciliation checklist before signing off on cutover, rather than assuming the automated extraction caught everything. This is the same checklist Sabee's own migration specialists use internally, shared with the customer so both sides are checking the same items:

• Arrivals and departures for the trailing 7 days — spot-check every reservation checking in or out in the week before cutover against the source system's own arrivals report, since these are the records most likely to be mid-edit at extraction time.
• Open folios and outstanding balances — confirm every in-house guest's current balance in Sabee matches the source system exactly, including any partial payments or split charges, before the source system goes read-only.
• Future group blocks and allotments — legacy systems often store group bookings differently from individual reservations; verify each future group block's room count, rate and cutoff date individually rather than trusting a bulk import summary.
• Deposit and no-show fee records — confirm any pending deposit due on a future reservation is correctly reflected as outstanding in Sabee, not silently marked paid or silently dropped during the mapping.
• Rate calendar spot-checks — pick five to ten dates across the next three months, spanning at least one seasonal rate change, and confirm the unrolled historical/forward rate calendar in Sabee matches the source system's rate grid exactly.
• Extras and package pricing — verify that normalised extras (breakfast, parking, late check-out fees) carry the correct current price, since legacy free-text extras are the field most likely to need manual correction after normalisation.
• User accounts and permissions — since legacy user accounts are rebuilt from scratch rather than migrated, confirm every current staff member has an account with the correct role before the source system is retired, not just the manager who ran the scoping call.
• Channel manager mapping, if newly connected — for properties adopting a channel manager for the first time as part of the move, confirm every room-type-to-listing mapping on Booking.com and Expedia individually rather than trusting a bulk auto-match, since a wrong mapping here risks selling the wrong room type entirely.

Working through this list typically takes a finance lead and a front-desk supervisor two to three hours combined, scheduled during week 7 alongside the final rehearsal migration, so any item that doesn't reconcile can be corrected before the live cutover rather than discovered afterward.