PMS hotelero: integración, migración y los errores que todos cometen
El PMS como núcleo (y cuello de botella) del hotel
El Property Management System es el sistema nervioso central de cualquier hotel. Reservas, check-in, check-out, facturación, housekeeping, tarifas. Todo pasa por el PMS. Y precisamente por eso, cuando un hotel necesita modernizar su tecnología, el PMS es simultáneamente el sistema más crítico de migrar y el más arriesgado de tocar.
El mercado de PMS hotelero en España está en plena transición. Los sistemas on-premise clásicos (Opera PMS de Oracle, Protel, Sihot) coexisten con una nueva generación cloud-native (Mews, Cloudbeds, Clock PMS+, Apaleo). Según STR Global, el 45% de los hoteles españoles independientes aún operan con PMS on-premise, frente al 28% en el norte de Europa. La brecha está cerrando, pero la migración no es trivial.
El paisaje de APIs: lo que cada PMS ofrece realmente
No todos los PMS son iguales en cuanto a capacidad de integración. La diferencia entre un PMS con API moderna y uno con conectores legacy determina qué integraciones son viables y a qué coste.
Oracle Opera Cloud (OHIP): La API más completa del mercado, pero también la más compleja. Soporta reservas, perfiles de huésped, tarifas, inventario, facturación y housekeeping. Autenticación OAuth 2.0, formato JSON, webhooks para eventos en tiempo real. El problema: la documentación es extensa pero desorganizada, y obtener credenciales de sandbox puede tardar semanas. Coste de integración típico: 15.000-40.000 euros dependiendo del alcance.
Mews Connector API: API REST moderna, bien documentada, con sandbox accesible en minutos. Cubre reservas, servicios, facturación, integraciones de pago y housekeeping. Los webhooks son fiables y el modelo de datos es limpio. Es el PMS más amigable para desarrolladores. Coste de integración típico: 5.000-15.000 euros.
Cloudbeds: API REST con buena cobertura de reservas y canal. La documentación ha mejorado significativamente en 2025. Fuerte en channel management nativo. Limitaciones en personalización de facturación y reporting avanzado. Coste de integración típico: 8.000-20.000 euros.
Sistemas legacy (Protel, Sihot, PMS locales): Muchos dependen de interfaces FIAS, ficheros planos o bases de datos compartidas. La integración requiere middleware custom y, en muchos casos, acceso directo a la base de datos del PMS, lo que introduce riesgos de estabilidad. Coste de integración: variable, desde 10.000 euros para algo básico hasta 50.000 para integraciones complejas con transformaciones de datos.
Migración de datos: dónde se rompen las cosas
La migración de un PMS a otro es un proyecto de datos antes que un proyecto de software. Los tres puntos críticos:
Perfiles de huéspedes. Son el activo más valioso y el más desordenado. Un hotel mediano de 150 habitaciones tiene entre 30.000 y 100.000 perfiles acumulados. Duplicados, campos vacíos, direcciones obsoletas, emails inválidos. 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 decisión final de merge siempre requiere revisión humana.
Histórico de reservas. El nuevo PMS necesita el histórico para reporting y para que los perfiles de huésped 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 transformación requiere un mapping detallado campo por campo y, inevitablemente, algunos datos se pierden o se degradan. Define qué datos son críticos (estancias, revenue, preferencias del huésped) 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 más 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 problemáticos. Recomendamos migrar solo las tarifas activas y futuras, no el histórico de tarifas (que ya está capturado en las reservas pasadas).
Channel manager: el conector crítico
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 migración de PMS, la conexión con el channel manager es el punto de mayor riesgo operativo.
El problema específico: durante el cambio, hay un periodo donde el PMS antiguo ya no actualiza disponibilidad y el nuevo aún no está conectado. Si ese periodo dura más de unas horas, generas overbookings. Lo hemos visto ocurrir.
La solución es coordinar el corte con el channel manager. El proceso típico:
- Configurar la conexión nuevo PMS - channel manager en paralelo (sin activar).
- Cerrar ventas en las OTAs 24-48 horas antes del corte (pérdida de revenue controlada).
- Ejecutar la migración de datos al nuevo PMS.
- Activar la conexión nuevo PMS - channel manager.
- Verificar paridad de tarifas y disponibilidad en todas las OTAs.
- 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
Después 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 después de migrar.” No. Los datos sucios en el nuevo PMS generan problemas desde el día uno: duplicados en el booking engine, emails de confirmación a direcciones inválidas, informes con revenue incorrecto. Limpia antes.
No involucrar a recepción en la migración. Los recepcionistas conocen los workarounds que el PMS antiguo requería. Saben qué campos se usaban de forma no estándar, qué datos están en notas libres en lugar de campos estructurados, y que procesos dependen de funcionalidades específicas. Sin su input, la migración pierde contexto crítico.
Hacer el corte en temporada alta. Parece obvio, pero ocurre. La ventana ideal es el periodo de menor ocupación: enero-febrero para hoteles de playa, noviembre para hoteles urbanos. Nunca en puentes ni festivos.
No tener rollback plan. Si la migración falla, necesitas poder volver al PMS antiguo en horas, no en días. Esto requiere mantener el PMS antiguo operativo (sin datos nuevos) durante al menos 2 semanas post-migración. El coste de la licencia duplicada es un seguro barato.
Ignorar la formación. Un PMS nuevo con un equipo que no sabe usarlo es peor que el PMS antiguo. Presupuesta 2-3 días de formación presencial para recepción, 1 día para revenue management, y 1 día para contabilidad. No es un coste; es una inversión que determina si el proyecto tiene éxito o no.
Qué preguntar antes de decidir
Si estás evaluando cambiar de PMS, las preguntas que determinan el éxito del proyecto no son sobre funcionalidades del software. Son sobre el proceso:
- Cuántos perfiles de huésped tenemos y en qué estado están?
- Qué integraciones críticas tenemos y cuál es su compatibilidad con el nuevo PMS?
- Cuál es nuestra ventana de mínima ocupación?
- Quién del equipo liderará la migración internamente?
- Qué datos necesitamos migrar y cuáles podemos archivar?
El PMS correcto es el que se integra con tu ecosistema (consulta nuestros patrones de integración ERP para los principios aplicables), no el que tiene más funcionalidades en la demo. Y la migración correcta es la que se planifica con el mismo rigor que una reforma del hotel: con planos, presupuesto y un plan B.