Migrar a cloud PMS: qué preguntas hacer antes de irte

La migración de un PMS on-premise a cloud no es un flip switch. Es una operación que toca datos, procesos, integraciones y flujo de caja. Y en la mayoría de casos, los hoteleros descubren lo que no preguntaron cuando ya está todo en marcha.

He visto hoteles que migraron sin acordar un plan de rollback, otros que descubrieron demasiado tarde que su channel manager no se sincronizaba bien con el nuevo sistema, y unos cuantos que pusieron cara de sorpresa cuando les llegó la primera factura cloud con sobrecostes por usuario o almacenamiento.

La diferencia entre una migración que funciona y una que te quita el sueño está en las preguntas que haces antes de firmar.

¿Cuánto downtime puedo permitirme?

Esta es la primera. Los proveedores cloud te venderán un plan de migración sin interrupciones (zero-downtime), pero la realidad es matizada. Algunos sistemas permiten un cutover progresivo donde conviven versiones durante días. Otros requieren un corte claro de 4, 8 o 24 horas.

Pregunta concreto: ¿qué ventanas de downtime tolera tu operación? Si mañana es temporada alta y tienes ocupación al 95%, un corte de 12 horas es una pesadilla. Si estás en marzo en una zona de playa, tal vez es manejable.

Y luego está el dato que muchos no prevén: aunque el PMS esté arriba, ¿qué pasa con tus integraciones críticas? El channel manager, el motor de reservas, el lock del pms con contabilidad. Una migración limpia debe certificar todas las integraciones antes del cutover, no después.

¿Quién carga mis datos históricos y cuándo?

Tus archivos on-premise contienen años de información: reservas, huéspedes, histórico de ocupación, configuración de tarifas. El proveedor cloud te dirá que lo migra automático. Pero la realidad es que esos datos no son oro puro: están sucios, con duplicados, con campos raros que el sistema viejo permitía y el nuevo no.

Pregunta: ¿el proveedor valida los datos antes de cargarlos en producción, o cargas mierda sobre ruedas desde el primer día? ¿Cuántos días de pruebas tienes en paralelo? Y lo importante: ¿quién paga si algo falla en esa carga?

Una buena práctica es que hagan una carga de test primero, que valides los números contra tus saldos actuales, y solo después hagan la carga de verdad.

¿Cómo se estructura el coste y qué pasa si crezco?

Aquí es donde chirría. Los PMS cloud usan modelos de pricing distintos: por usuario activo, por habitación, por transacción, híbridos. Y cada modelo escala diferente.

Un director de operaciones que abre una nueva propiedad de 120 cuartos puede estar pagando modelos lineales (lo multiplicas por 1,3x) o puede estar en un contrato con cláusulas de escalado que no aplicas hasta renovación. Otros sistemas cargan por concurrencia, otros por consumo de API.

Pregunta: ¿cómo crece el coste si añado 50 habitaciones? ¿Si abro una nueva propiedad? ¿Si necesito módulos adicionales (revenue management, housekeeping avanzado)? ¿Hay penalizaciones por baja de usuarios o es flexible?

Y atención a un detalle que muchos se saltan: algunos proveedores incluyen cierto volumen de integraciones, pero cada integración premium (una conexión personalizada a tu sistema de contabilidad, por ejemplo) suma euros que no estaban en la propuesta inicial.

¿Qué ocurre con mis datos si quiero irme?

Es la pregunta del paracaidista: ¿puedo saltar si algo sale mal? Los proveedores serios te darán datos en formato estándar (CSV, JSON, XML), con un período de gracia para exportarlos tras terminar el contrato. Otros te ponen trabas.

Pregunta: ¿cuántos días tienes para descargar tus datos después de cancelar? ¿En qué formato? ¿Hay costes adicionales de exportación? ¿Puedo migrar a otro PMS sin perder dos años de histórico?

Esta es tu póliza de seguros. No es que esperes usarla, pero te deja dormir tranquilo.

¿Quién soporta la migración día a día?

Al final, alguien tiene que estar en el Zoom cuando falla la sincronización a las 15:00 de un viernes. ¿El proveedor cloud te dedica un gestor de proyecto durante el cutover? ¿Cuántas horas de soporte incluye? ¿Hay un SLA (service level agreement) que te ampare si cae el sistema después de migrar?

Un buen contrato de migración debe especificar: responsable de cada fase, timeline exacto, quién resuelve qué problema, y cuál es el plan B si todo se tuerce.

Conclusión

La migración a cloud es una oportunidad para limpiar procesos, centralizar datos y ganar flexibilidad operativa. Pero es una oportunidad que solo funciona si entra en la fase de ejecución con preguntas respondidas y acuerdos por escrito.

No es paranoia. Es profesionalismo. El hotelero que hace estas preguntas antes de firmar es el que luego no está explicando por qué su revenue manager no ve los datos correctos o por qué le llegó una factura sorpresa.

Migra, pero migra con los ojos abiertos.