Hotel PMS: Integration, Migration and the Mistakes Everyone Makes

The PMS as the hotel’s backbone (and bottleneck)

The Property Management System is the central nervous system of any hotel. Reservations, check-in, check-out, billing, housekeeping, rates. Everything flows through the PMS. And precisely because of that, when a hotel needs to modernize its technology, the PMS is simultaneously the most critical system to migrate and the riskiest to touch.

The hotel PMS market is in full transition. Classic on-premise systems (Oracle Opera PMS, Protel, Sihot) coexist with a new generation of cloud-native platforms (Mews, Cloudbeds, Clock PMS+, Apaleo). According to STR Global, 45% of independent hotels in Southern Europe still operate on-premise PMS, versus 28% in Northern Europe. The gap is closing, but migration is not trivial.

The API landscape: what each PMS actually offers

Not all PMS platforms are equal in integration capability. The difference between a PMS with a modern API and one with legacy connectors determines which integrations are viable and at what cost.

Oracle Opera Cloud (OHIP): The most comprehensive API on the market, but also the most complex. Supports reservations, guest profiles, rates, inventory, billing, and housekeeping. OAuth 2.0 authentication, JSON format, webhooks for real-time events. The problem: documentation is extensive but disorganized, and obtaining sandbox credentials can take weeks. Typical integration cost: EUR 15,000-40,000 depending on scope.

Mews Connector API: Modern REST API, well-documented, with sandbox accessible in minutes. Covers reservations, services, billing, payment integrations, and housekeeping. Webhooks are reliable and the data model is clean. The most developer-friendly PMS. Typical integration cost: EUR 5,000-15,000.

Cloudbeds: REST API with good reservation and channel coverage. Documentation improved significantly in 2025. Strong in native channel management. Limitations in billing customization and advanced reporting. Typical integration cost: EUR 8,000-20,000.

Legacy systems (Protel, Sihot, local PMS): Many depend on FIAS interfaces, flat files, or shared databases. Integration requires custom middleware and, in many cases, direct access to the PMS database, introducing stability risks. Integration cost: variable, from EUR 10,000 for basics to EUR 50,000 for complex integrations with data transformations.

Data migration: where things break

Migrating from one PMS to another is a data project before it is a software project. The three critical areas:

Guest profiles. The most valuable asset and the messiest. A mid-sized 150-room hotel accumulates 30,000 to 100,000 profiles. Duplicates, empty fields, obsolete addresses, invalid emails. Before migrating, you must clean. Cleaning consumes 40% of total project time in our experience. Tools like Dedupe.io or custom scripts with fuzzy matching (Levenshtein, Jaro-Winkler) identify duplicates, but the final merge decision always requires human review.

Reservation history. The new PMS needs history for reporting and to give guest profiles context. But data models across PMS platforms are incompatible. Opera structures reservations as “legs” with segments. Mews uses “reservations” with “items.” Cloudbeds has its own model. Transformation requires detailed field-by-field mapping and, inevitably, some data is lost or degraded. Define which data is critical (stays, revenue, guest preferences) and which is expendable (old internal notes, 2019 minibar records) before you start.

Rates and contracts. Rate structure (rate plans, packages, promotions, tour operator contracts) is the most complex part to migrate because every PMS models it differently. A “rate plan” in Opera does not map 1:1 to a “rate” in Mews. Tour operator contracts with allotments, release periods, and net prices are particularly problematic. We recommend migrating only active and future rates, not historical rates (which are already captured in past reservations).

Channel manager: the critical connector

The channel manager (SiteMinder, D-EDGE, TravelClick, RateTiger) connects the PMS to OTAs (Booking.com, Expedia, Airbnb) and the direct booking engine. During a PMS migration, the channel manager connection is the point of highest operational risk.

The specific problem: during the switch, there is a period when the old PMS no longer updates availability and the new one is not yet connected. If that period extends beyond a few hours, you generate overbookings. We have seen it happen.

The solution is coordinating the cutover with the channel manager. Typical process:

1. Configure new PMS - channel manager connection in parallel (without activating).
2. Close sales on OTAs 24-48 hours before cutover (controlled revenue loss).
3. Execute data migration to the new PMS.
4. Activate the new PMS - channel manager connection.
5. Verify rate and availability parity across all OTAs.
6. Reopen sales.

Step 2 hurts (nobody wants to close sales), but it is infinitely better than managing 15 overbookings in peak season.

The five mistakes everyone makes

After participating in PMS migrations for hospitality properties ranging from 50 to 300 rooms, these are the recurring mistakes.

Underestimating data cleanup. “We will clean up after migration.” No. Dirty data in the new PMS generates problems from day one: duplicates in the booking engine, confirmation emails to invalid addresses, reports with incorrect revenue. Clean first.

Not involving front desk in the migration. Receptionists know the workarounds the old PMS required. They know which fields were used non-standardly, which data sits in free-text notes instead of structured fields, and which processes depend on specific features. Without their input, the migration loses critical context.

Cutting over during peak season. Seems obvious, yet it happens. The ideal window is the lowest-occupancy period: January-February for beach hotels, November for urban hotels. Never during holiday weekends.

No rollback plan. If migration fails, you need to revert to the old PMS in hours, not days. This requires keeping the old PMS operational (without new data) for at least 2 weeks post-migration. The cost of a duplicate license is cheap insurance.

Skipping training. A new PMS with a team that does not know how to use it is worse than the old PMS. Budget 2-3 days of in-person training for front desk, 1 day for revenue management, and 1 day for accounting. It is not a cost; it is the investment that determines whether the project succeeds.

What to ask before deciding

If you are evaluating a PMS change, the questions that determine project success are not about software features. They are about the process:

• How many guest profiles do we have and what state are they in?
• What critical integrations do we have and what is their compatibility with the new PMS?
• What is our minimum-occupancy window?
• Who on the team will lead the migration internally?
• What data do we need to migrate and what can we archive?

The right PMS is the one that integrates with your ecosystem (see our ERP integration patterns for the applicable principles), not the one with the most features in the demo. And the right migration is one planned with the same rigor as a hotel renovation: with blueprints, a budget, and a plan B.