Migración de OPERA 5 a OPERA Cloud: la lista de comprobación para hoteles

Todo hotel con OPERA 5 ha oído alguna versión de «tienen que migrar» de boca de un proveedor con algo que vender. La realidad es menos dramática y más útil: Oracle publica fechas de soporte exactas, la migración cambia aspectos concretos de la operativa diaria y los hoteles que tropiezan suelen ser los que la trataron como un proyecto de informática y no como un proyecto operativo. Esta lista de comprobación recoge lo que está realmente documentado, lo que cambia, cómo se trasladan los datos y las interfaces, qué aprendió el equipo de una de las mayores migraciones de OPERA 5 y cómo mantener la comunicación con los huéspedes durante el cambio, con la integración de chatlyn con OPERA 5 on-premise antes del cutover y la integración con Oracle OPERA Cloud después.

En resumen

• OPERA 5.6, la última versión on-premise, tiene Premier Support hasta diciembre de 2027. No hay Extended Support ni una fecha de apagado publicada.
• OPERA Cloud es software alojado por Oracle que se usa en el navegador, actualizado por Oracle varias veces al año, con las funciones nuevas desactivadas hasta que usted las activa.
• Las interfaces pasan a OHIP, la plataforma de API de Oracle, proveedor a proveedor. Algunas interfaces heredadas, entre ellas OXI, siguen funcionando con OPERA Cloud.
• Los datos se trasladan con la herramienta de migración de Oracle o con una instalación desde cero. Límpielos antes: llegan exactamente como salen.
• La comunicación con los huéspedes puede seguir sin interrupción, porque los mismos recorridos del huésped funcionan en ambos sistemas.

En qué punto está el soporte de OPERA 5

Las fechas que conviene conocer proceden de la propia Applications Lifetime Support Policy de Oracle, no de presentaciones de proveedores. En la edición de agosto de 2026:

Durante la ampliación hasta diciembre de 2027, la corrección de errores solo se aplica a OPERA 5.6.28 y posteriores, así que un hotel con una compilación 5.6 anterior tiene motivos para actualizar incluso antes de migrar. La versión 5.5 salió del Premier Support en octubre de 2021, una transición que el partner de Oracle Mastel Hospitality documentó en su momento para sus clientes.

Hay dos matices importantes. Primero, no existe una fecha de apagado publicada: cuando termina el Premier Support, OPERA 5 pasa a Sustaining Support de forma indefinida, lo que significa que el software sigue funcionando, pero dejan de llegar correcciones, actualizaciones y certificaciones. Segundo, Oracle ya ha ampliado antes la fecha de la 5.6, así que consulte el documento de la política vigente para su versión en lugar de fiarse de cualquier artículo, este incluido. La pregunta operativa no es «cuándo muere OPERA 5», sino «cuánto tiempo queremos gestionar la recepción con un sistema que ya no recibe correcciones».

OPERA 5 y OPERA Cloud, cara a cara

OPERA Cloud no es OPERA 5 en un navegador: es un sistema distinto con el mismo vocabulario. La tabla resume lo que dice la documentación de Oracle sobre cada uno.

Para los huéspedes, nada de esto debería notarse. Los mismos recorridos del huésped pueden funcionar en ambos sistemas, así que solo cambia la fuente de datos que hay detrás de los mensajes:

Qué cambia en el día a día con la migración

Los equipos cuentan que los flujos de trabajo habituales cambian de forma, que las pantallas se organizan de otra manera y que algunas tareas requieren más clics de los que la memoria muscular espera, lo que convierte la formación en una línea de trabajo real y no en un trámite. Tres ámbitos merecen un responsable propio.

Informes. Los informes estándar de OPERA Cloud se pueden copiar con parámetros predefinidos, programar y ejecutar para varios hoteles desde un hub, pero la documentación de Oracle deja claro que no muestran los campos flexibles personalizados ni admiten localización. Los informes personalizados se hacen en Reporting and Analytics, que se contrata aparte. Los equipos que vivían en informes personalizados de OPERA 5 deberían hacer una lista de los informes que de verdad usan y crear un prototipo de cada uno antes del cutover.

Pagos. OPERA Cloud procesa los pagos mediante la Oracle Payment Interface. OPI Cloud conecta de nube a nube con su proveedor de pagos y añade opciones como Pay By Link y la tokenización. Los hoteles no siempre lo cambian todo a la vez: Rotana utilizó primero OPERA Cloud con OPI on-premise y después trasladó 21 hoteles de Emiratos Árabes Unidos a OPI Cloud tras un hotel piloto, según el caso de éxito de su proveedor de pagos. Confirme pronto que su proveedor está certificado para la configuración de destino y cómo se trasladan los tokens de tarjeta guardados.

Actualizaciones. En lugar de proyectos de actualización cada pocos años, OPERA Cloud cambia varias veces al año. Muchas funciones nuevas llegan desactivadas, así que alguien tiene que leer las guías de release readiness de Oracle y decidir qué se activa. Ese papel no existía con OPERA 5.

Cómo se trasladan sus datos a OPERA Cloud

Oracle ofrece una herramienta oficial, OPERA to Cloud Migration. El hotel ejecuta un pequeño componente en su servidor de base de datos que establece una transferencia de archivos segura y genera un informe de evaluación; después, el equipo de migración de Oracle realiza una transferencia inicial de datos y, más tarde, una final justo antes de la puesta en marcha. La solicitud se tramita a través del departamento comercial de Oracle, y la herramienta es compatible con las versiones de OPERA a partir de la 5.0.03.03.

Oracle Consulting ha descrito dos caminos. Una migración completa traslada datos, historial, reservas y configuración, pero exige datos limpios y una migración de prueba previa, y puede suponer un tiempo de inactividad considerable. Una instalación nueva empieza desde cero, importa la configuración y traslada reservas y perfiles mediante un tercero, con una inactividad limitada al propio cutover. Existen herramientas de terceros para este segundo camino; una de ellas traslada perfiles, reservas, códigos de tarifa, paquetes y datos financieros a través de OXI, y aun así requiere mapear códigos allí donde los valores no coinciden uno a uno.

En cualquier caso, la regla de quienes lo han vivido se cumple: los datos sucios migran como datos sucios. Los perfiles de huésped duplicados, los códigos de tarifa incoherentes y las reglas de routing antiguas llegan intactos y después perjudican los informes y el trabajo de recepción en el nuevo sistema. Limpie antes de la primera transferencia, no después de la puesta en marcha.

Interfaces: qué pasa a OHIP y qué sigue funcionando

En OPERA Cloud, las integraciones nuevas utilizan OHIP, la plataforma de API de Oracle. Los datos salientes fluyen como business events, que el sistema conectado recibe por streaming o por polling, y Oracle recomienda el streaming. Los datos entrantes utilizan las API REST de OHIP.

Dos detalles condicionan cualquier plan de interfaces:

• Los códigos deben coincidir uno a uno. OXI permitía mapear los códigos de OPERA con los de otro sistema, como tipos de habitación, códigos de tarifa y paquetes. La documentación de OHIP de Oracle indica que las API REST ya no siguen este enfoque: los códigos deben coincidir uno a uno, o el otro sistema tiene que encargarse del mapeo por su lado. Eso supone trabajo adicional con cada proveedor, y debe figurar en el plan desde el primer día.
• Las interfaces heredadas no han desaparecido. OPERA Cloud sigue admitiendo las interfaces de hotel OXI, OEDS, OFIS y FIAS, cada una con su propia cuenta de servicio de interfaz, y las interfaces a nivel de hotel funcionan mediante un agente de software instalado en hardware en sus instalaciones. Oracle también señala algunas operaciones de IFC8 que aún no están disponibles en REST, y funciones de membresía de OPERA Web Services que todavía no están en REST. Pregunte a cada proveedor qué vía utilizará, OHIP o heredada, y cuándo.

El documento más útil de todo el proyecto es un sencillo inventario de interfaces. Un punto de partida:

Si OHIP es terreno nuevo para usted, nuestra guía en lenguaje sencillo ¿qué es OHIP? explica qué hace la plataforma y qué implica conectar a un proveedor.

Big bang o por fases: lo que aprendió Thon Hotels

La migración de OPERA 5 mejor documentada es la de Thon Hotels en Noruega. Según el propio artículo de Oracle, Thon trasladó 96 hoteles de OPERA 5 on-premise a OPERA Cloud en 31 horas, con la puesta en marcha el 8 de abril de 2024. Oracle Consulting había recomendado el enfoque habitual por fases; Thon optó por un «big bang» para no mantener dos bases de datos maestras en paralelo, y Oracle describe ahora el big bang como una opción de implantación estándar.

Lo que hizo que funcionara:

• Un grupo de proyecto unos seis meses antes, con la estandarización entre hoteles hecha primero.
• La formación terminó tres semanas antes de la puesta en marcha, en la plataforma de aprendizaje de Oracle, con superusuarios designados en cada hotel.
• Un plan alternativo ensayado. En la última semana, todos los hoteles practicaron el registro de check-ins y de housekeeping en hojas de cálculo para las horas, y posiblemente días, de inactividad.
• Primero, los pilotos. Unos centros de mando dirigieron el cambio: cinco hoteles piloto fueron los primeros y probaron las interfaces y las transacciones con tarjeta, y después siguieron grupos de diez.
• Sin funcionamiento en paralelo. Unos 2.000 usuarios de OPERA 5 se dieron de baja la mañana de la puesta en marcha, y el personal trabajó en OPERA Cloud al día siguiente.

Otros grandes grupos también se han movido rápido, de otras maneras. Motel One llevó más de 100 hoteles en 13 países a OPERA Cloud en unos cuatro meses, con una media de 14 puestas en marcha por semana, y trasladó sus registros operativos y financieros, los saldos de huéspedes y de contabilidad, y el estado de habitaciones y de housekeeping. PPHE Hotel Group, usuario de OPERA 5 desde hace años, anunció en noviembre de 2025 su paso a OPERA Cloud para 18 hoteles y 5.200 habitaciones.

Mantener la comunicación con los huéspedes

La comunicación con los huéspedes es uno de los pocos sistemas que pueden mantenerse sin interrupción durante toda la migración, porque chatlyn es compatible con ambos lados. En OPERA 5, la integración con Oracle OPERA on-premise gestiona los recorridos del huésped a partir de informes programados a través de una conexión SFTP segura. En OPERA Cloud, la integración con Oracle OPERA Cloud se suscribe a eventos en tiempo real a través de OHIP. El hotel pasa de una a otra durante el cutover, junto con nuestro equipo de customer success, y lo que ve el huésped, es decir, confirmaciones, mensajes previos a la llegada y respuestas de la IA en WhatsApp, chat web, Facebook Messenger, Instagram y las bandejas de Booking.com de nueva creación, continúa sin cambios.

En grupos con sistemas mixtos, esta misma doble compatibilidad permite migrar hotel por hotel mientras cada establecimiento sigue escribiendo a sus clientes. Y algunos hábitos hacen que el fin de semana del cutover sea más tranquilo para el huésped:

• Mantenga la bandeja de entrada atendida. Si el check-in se detiene mientras cambian los sistemas, los clientes escriben. La IA responde a las preguntas habituales con su propia información, y una persona designada se encarga de todo lo demás.
• Pause las campañas, no los recorridos. Las confirmaciones y los mensajes previos a la llegada deben seguir enviándose; los envíos de marketing pueden esperar una semana.
• Cuéntele a la IA lo que está pasando. Una breve nota en su base de conocimiento sobre los check-ins más lentos de ese fin de semana le permite responder con honestidad.
• Haga una prueba el primer día. Cree una reserva de prueba en OPERA Cloud y compruebe que la confirmación llega en cuestión de instantes.

Los problemas que los hoteles encuentran de verdad

Lecciones recurrentes de profesionales, consultores y migraciones publicadas:

• Los datos sucios migran como datos sucios. Años de uso incoherente de OPERA 5, sobre todo los perfiles de huésped duplicados, llegan intactos a OPERA Cloud si no se limpian antes.
• El proveedor más lento marca el ritmo. Cada interfaz necesita una vía OHIP o heredada y códigos alineados, y un solo proveedor con retraso puede frenar la puesta en marcha.
• Hay que rehacer los informes. Los informes personalizados de OPERA 5 no se trasladan solos; cree prototipos de los importantes en OPERA Cloud o en Reporting and Analytics antes del cutover.
• La formación es mayor de lo previsto. Los usuarios hablan de flujos de trabajo distintos y más clics para tareas rutinarias; a los hoteles que mejor les va terminan la formación antes de la puesta en marcha y mantienen un superusuario por turno.
• El cutover detiene la operativa. El check-in, los pagos y las actualizaciones de housekeeping pueden quedar en pausa durante el cambio, así que planifique la ventana para un periodo de baja ocupación y ensaye el plan alternativo manual.
• Nadie se ocupa de las notas de versión. Tras la puesta en marcha, llegan funciones desactivadas varias veces al año. Sin un responsable, el hotel nunca les saca partido.

Nada de esto es un argumento en contra de migrar. Es un argumento a favor de tratar la migración como un programa operativo, con un responsable, una fase de limpieza de datos y un plan de interfaces proveedor a proveedor.

La semana del cutover, paso a paso

Una secuencia de ejemplo, basada en la herramienta de migración de Oracle y en la puesta en marcha documentada de Thon:

1. Última semana: congele los cambios de configuración, ensaye el plan alternativo manual para el check-in y el housekeeping y confirme los pasos de puesta en marcha de cada proveedor.
2. Día anterior: últimas comprobaciones de las interfaces y las transacciones con tarjeta en el entorno de pruebas; informe a cada turno; asegure personal para la bandeja de entrada de huéspedes.
3. Cutover: transferencia final de datos, baja de los usuarios de OPERA 5 y cambio de las interfaces, incluida la mensajería con huéspedes, a sus vías de OPERA Cloud.
4. Primeras horas: transacciones piloto de principio a fin: una reserva, un check-in, un pago con tarjeta y un mensaje de confirmación a un huésped de prueba.
5. Primeras dos semanas: una revisión diaria con superusuarios y proveedores, una lista de incidencias abiertas y un repaso rápido de los informes frente al sistema anterior.

La lista de comprobación

Antes de empezar

1. Confirme su versión de OPERA 5 y sus fechas de soporte en la política de soporte vigente de Oracle, y actualice a la 5.6.28 o posterior si tiene una anterior.
2. Elija su camino: migración completa con historial o instalación nueva con datos seleccionados.
3. Designe un responsable del programa y un superusuario por departamento.

Datos e interfaces

4. Limpie los datos antes de la primera transferencia: perfiles de huésped, códigos de tarifa, reglas de routing.
5. Elabore el inventario de interfaces, con la vía de cada proveedor (OHIP o heredada), la alineación de códigos y la fecha de puesta en marcha.
6. Confirme la certificación de su proveedor de pagos y cómo se trasladan los tokens de tarjeta.
7. Cree prototipos de sus informes más utilizados en OPERA Cloud o en Reporting and Analytics.

Personas y puesta en marcha

8. Termine la formación antes de la puesta en marcha, con tiempo para practicar.
9. Programe el cutover para un periodo de baja ocupación, con un plan alternativo manual ensayado.
10. Planifique la comunicación con los huéspedes para el fin de semana del cutover: recorridos activos, campañas en pausa y bandeja de entrada atendida.
11. Tras la puesta en marcha, compruebe de principio a fin el flujo de eventos de OHIP: una reserva de prueba debe activar el mensaje de confirmación en cuestión de instantes.
12. Designe a alguien que lea cada versión de OPERA Cloud y decida qué funciones nuevas se activan.

Preguntas frecuentes

¿Ha llegado OPERA 5 al final de su vida útil? Oracle no publica ninguna fecha de apagado. La última versión con soporte, la 5.6, tiene Premier Support hasta diciembre de 2027 según la política de soporte vigente de Oracle, sin nivel de Extended Support; después pasa a un Sustaining Support indefinido, sin nuevas correcciones ni certificaciones. Consulte la política para su versión exacta.

¿Cuánto dura una migración de OPERA 5 a OPERA Cloud? Depende mucho más de la preparación que del cambio en sí. Thon Hotels formó su grupo de proyecto unos seis meses antes y después trasladó 96 hoteles en un único cutover de 31 horas; Motel One llevó más de 100 hoteles a OPERA Cloud en unos cuatro meses. La limpieza de datos, la preparación de las interfaces y la formación suelen ser lo que fija la fecha.

¿Perdemos nuestras integraciones al migrar? Cada interfaz necesita una vía en OPERA Cloud: las API REST y los business events de OHIP, o una de las interfaces heredadas que OPERA Cloud sigue admitiendo, como OXI. En las API REST los códigos deben coincidir uno a uno, así que cada proveedor necesita un plan. chatlyn es compatible con ambos lados: recorridos basados en SFTP en OPERA 5 hoy y eventos de OHIP en tiempo real en OPERA Cloud después, de modo que la comunicación con los huéspedes continúa durante el cambio.

¿Sigue disponible OXI con OPERA Cloud? Sí, como interfaz heredada. La documentación de OPERA Cloud incluye las interfaces de hotel OXI, OEDS, OFIS y FIAS, cada una con su propia cuenta de servicio de interfaz. Para las integraciones nuevas, Oracle apuesta por OHIP.

¿Qué pasa con nuestros informes personalizados de OPERA 5? Cuente con rehacerlos. Los informes estándar de OPERA Cloud cubren la operativa diaria, y los informes personalizados se hacen en Reporting and Analytics de Oracle, un servicio que se contrata aparte. Haga una lista de los informes que su equipo usa de verdad y cree prototipos antes del cutover.

¿Tenemos que cambiar nuestra interfaz de pagos? OPERA Cloud procesa los pagos mediante la Oracle Payment Interface, incluido OPI Cloud. Que su configuración actual cambie o no depende de su proveedor de pagos, así que confirme al principio del proyecto su certificación y cómo se trasladan los tokens de tarjeta guardados.

¿Migración big bang o por fases? Las dos funcionan. Oracle Consulting recomendaba tradicionalmente una implantación por fases; Thon Hotels eligió un big bang para evitar dos bases de datos maestras, y Oracle lo ofrece ahora como opción estándar. Las implantaciones por fases convienen a los grupos que quieren aprender primero de un hotel piloto.

¿Puede seguir funcionando la mensajería con huéspedes durante el cutover? Sí. Los recorridos funcionan con la integración on-premise hasta el cutover y con OHIP después; la IA sigue respondiendo a los huéspedes en WhatsApp, chat web, Facebook Messenger, Instagram y las bandejas de Booking.com de nueva creación durante todo el proceso, y solo cambia la fuente de datos que hay detrás de los recorridos.

Fuentes

• Oracle Applications Lifetime Support Policy (edición de agosto de 2026)
• Mastel Hospitality: actualización de la política de soporte de OPERA 5.5
• Documentación de Oracle OHIP: migración de las API heredadas a REST y OPERA Xchange Interface (OXI)
• Documentación de Oracle OHIP: interfaces de hotel (IFC8, FIAS) y business events
• Documentación de Oracle OPERA Cloud 26.4: informes, usuarios de interfaz y release readiness
• Oracle Hospitality Cloud Services: descripciones de servicio y métricas
• Oracle OPERA to Cloud Migration: guía para clientes y Oracle Consulting: el camino hacia OPERA Cloud
• Documentación de Oracle Payment Interface Cloud y Planet: caso de éxito de Rotana Hotels
• Oracle: la migración big bang de Thon Hotels a OPERA Cloud
• Lodging: Motel One lleva más de 100 hoteles a OPERA Cloud y Oracle: PPHE Hotel Group implanta OPERA Cloud
• Beyond: lecciones de la migración de datos a OPERA Cloud
• Opiniones de usuarios en Capterra y Hotel Tech Report