PMS hotelero: integracion, migracion y los errores que todos cometen

El PMS como nucleo (y cuello de botella) del hotel

El Property Management System es el sistema nervioso central de cualquier hotel. Reservas, check-in, check-out, facturacion, housekeeping, tarifas. Todo pasa por el PMS. Y precisamente por eso, cuando un hotel necesita modernizar su tecnologia, el PMS es simultaneamente el sistema mas critico de migrar y el mas arriesgado de tocar.

El mercado de PMS hotelero en Espana esta en plena transicion. Los sistemas on-premise clasicos (Opera PMS de Oracle, Protel, Sihot) coexisten con una nueva generacion cloud-native (Mews, Cloudbeds, Clock PMS+, Apaleo). Segun STR Global, el 45% de los hoteles espanoles independientes aun operan con PMS on-premise, frente al 28% en el norte de Europa. La brecha esta cerrando, pero la migracion no es trivial.

El paisaje de APIs: lo que cada PMS ofrece realmente

No todos los PMS son iguales en cuanto a capacidad de integracion. La diferencia entre un PMS con API moderna y uno con conectores legacy determina que integraciones son viables y a que coste.

Oracle Opera Cloud (OHIP): La API mas completa del mercado, pero tambien la mas compleja. Soporta reservas, perfiles de huesped, tarifas, inventario, facturacion y housekeeping. Autenticacion OAuth 2.0, formato JSON, webhooks para eventos en tiempo real. El problema: la documentacion es extensa pero desorganizada, y obtener credenciales de sandbox puede tardar semanas. Coste de integracion tipico: 15.000-40.000 euros dependiendo del alcance.

Mews Connector API: API REST moderna, bien documentada, con sandbox accesible en minutos. Cubre reservas, servicios, facturacion, integraciones de pago y housekeeping. Los webhooks son fiables y el modelo de datos es limpio. Es el PMS mas amigable para desarrolladores. Coste de integracion tipico: 5.000-15.000 euros.

Cloudbeds: API REST con buena cobertura de reservas y canal. La documentacion ha mejorado significativamente en 2025. Fuerte en channel management nativo. Limitaciones en personalizacion de facturacion y reporting avanzado. Coste de integracion tipico: 8.000-20.000 euros.

Sistemas legacy (Protel, Sihot, PMS locales): Muchos dependen de interfaces FIAS, ficheros planos o bases de datos compartidas. La integracion requiere middleware custom y, en muchos casos, acceso directo a la base de datos del PMS, lo que introduce riesgos de estabilidad. Coste de integracion: variable, desde 10.000 euros para algo basico hasta 50.000 para integraciones complejas con transformaciones de datos.

Migracion de datos: donde se rompen las cosas

La migracion de un PMS a otro es un proyecto de datos antes que un proyecto de software. Los tres puntos criticos:

Perfiles de huespedes. Son el activo mas valioso y el mas desordenado. Un hotel mediano de 150 habitaciones tiene entre 30.000 y 100.000 perfiles acumulados. Duplicados, campos vacios, direcciones obsoletas, emails invalidos. Antes de migrar, hay que limpiar. La limpieza consume el 40% del tiempo total del proyecto en nuestra experiencia. Herramientas como Dedupe.io o scripts custom con fuzzy matching (Levenshtein, Jaro-Winkler) identifican duplicados, pero la decision final de merge siempre requiere revision humana.

Historico de reservas. El nuevo PMS necesita el historico para reporting y para que los perfiles de huesped tengan contexto. Pero los modelos de datos entre PMS son incompatibles. Opera estructura las reservas como “legs” con segmentos. Mews usa “reservations” con “items.” Cloudbeds tiene su propio modelo. La transformacion requiere un mapping detallado campo por campo y, inevitablemente, algunos datos se pierden o se degradan. Define que datos son criticos (estancias, revenue, preferencias del huesped) y cuales son prescindibles (notas internas antiguas, registros de minibar de 2019) antes de empezar.

Tarifas y contratos. La estructura de tarifas (rate plans, paquetes, promociones, contratos con touroperadores) es la parte mas compleja de migrar porque cada PMS la modela de forma diferente. Un “rate plan” en Opera no mapea 1:1 a un “rate” en Mews. Los contratos con touroperadores que incluyen allotments, release periods y precios netos son particularmente problematicos. Recomendamos migrar solo las tarifas activas y futuras, no el historico de tarifas (que ya esta capturado en las reservas pasadas).

Channel manager: el conector critico

El channel manager (SiteMinder, D-EDGE, TravelClick, RateTiger) conecta el PMS con las OTAs (Booking.com, Expedia, Airbnb) y el booking engine directo. Durante una migracion de PMS, la conexion con el channel manager es el punto de mayor riesgo operativo.

El problema especifico: durante el cambio, hay un periodo donde el PMS antiguo ya no actualiza disponibilidad y el nuevo aun no esta conectado. Si ese periodo dura mas de unas horas, generas overbookings. Lo hemos visto ocurrir.

La solucion es coordinar el corte con el channel manager. El proceso tipico:

1. Configurar la conexion nuevo PMS - channel manager en paralelo (sin activar).
2. Cerrar ventas en las OTAs 24-48 horas antes del corte (perdida de revenue controlada).
3. Ejecutar la migracion de datos al nuevo PMS.
4. Activar la conexion nuevo PMS - channel manager.
5. Verificar paridad de tarifas y disponibilidad en todas las OTAs.
6. Reabrir ventas.

El punto 2 duele (nadie quiere cerrar ventas), pero es infinitamente mejor que gestionar 15 overbookings en temporada alta.

Los cinco errores que todos cometen

Despues de participar en migraciones de PMS para hoteles de hospitality de entre 50 y 300 habitaciones, estos son los errores recurrentes.

Subestimar la limpieza de datos. “Ya limpiaremos despues de migrar.” No. Los datos sucios en el nuevo PMS generan problemas desde el dia uno: duplicados en el booking engine, emails de confirmacion a direcciones invalidas, informes con revenue incorrecto. Limpia antes.

No involucrar a recepcion en la migracion. Los recepcionistas conocen los workarounds que el PMS antiguo requeria. Saben que campos se usaban de forma no estandar, que datos estan en notas libres en lugar de campos estructurados, y que procesos dependen de funcionalidades especificas. Sin su input, la migracion pierde contexto critico.

Hacer el corte en temporada alta. Parece obvio, pero ocurre. La ventana ideal es el periodo de menor ocupacion: enero-febrero para hoteles de playa, noviembre para hoteles urbanos. Nunca en puentes ni festivos.

No tener rollback plan. Si la migracion falla, necesitas poder volver al PMS antiguo en horas, no en dias. Esto requiere mantener el PMS antiguo operativo (sin datos nuevos) durante al menos 2 semanas post-migracion. El coste de la licencia duplicada es un seguro barato.

Ignorar la formacion. Un PMS nuevo con un equipo que no sabe usarlo es peor que el PMS antiguo. Presupuesta 2-3 dias de formacion presencial para recepcion, 1 dia para revenue management, y 1 dia para contabilidad. No es un coste; es una inversion que determina si el proyecto tiene exito o no.

Que preguntar antes de decidir

Si estas evaluando cambiar de PMS, las preguntas que determinan el exito del proyecto no son sobre funcionalidades del software. Son sobre el proceso:

• Cuantos perfiles de huesped tenemos y en que estado estan?
• Que integraciones criticas tenemos y cual es su compatibilidad con el nuevo PMS?
• Cual es nuestra ventana de minima ocupacion?
• Quien del equipo liderara la migracion internamente?
• Que datos necesitamos migrar y cuales podemos archivar?

El PMS correcto es el que se integra con tu ecosistema (consulta nuestros patrones de integracion ERP para los principios aplicables), no el que tiene mas funcionalidades en la demo. Y la migracion correcta es la que se planifica con el mismo rigor que una reforma del hotel: con planos, presupuesto y un plan B.