Cut-over terminado. ¿Y ahora qué?

PF Database Consulting  |  pfdbconsulting.com

Categoría: Estrategia de Migración  |  Junio 2026

Lo que hay que resolver después del go-live de Oracle y los errores que suelen ocurrir en esa etapa

El cut-over terminó. Los sistemas están en la nube. El equipo está exhauso y aliviado al mismo tiempo. En la sala hay una mezcla de orgullo genuino y cansancio acumulado.

Es exactamente en ese momento cuando ocurren los errores más caros de toda la migración.

No durante la ejecución. No en el diseño. Después del go-live, cuando baja la guardia, cuando el proyecto se considera cerrado y cuando las decisiones importantes se toman apuradas o directamente no se toman.

Este artículo documenta qué hay que resolver en las horas, días y semanas posteriores al cut-over, y cuáles son los errores más frecuentes que se cometen en esa etapa.

El post-cutover no es el final del proyecto. Es la etapa donde se consolida o se pierde todo lo que se logró hasta ese momento.

Parte 1 — Qué hay que resolver después del cut-over

1. Validación funcional inmediata (primeras 2 horas)

Antes de declarar el go-live exitoso hay que confirmar que los sistemas críticos están operando correctamente. Esto no es un test técnico completo, es una verificación de supervivencia.

Qué debe cubrirse en esta ventana:

•       Acceso a las bases de datos desde las aplicaciones críticas.

•       Ejecución de transacciones representativas del negocio.

•       Integraciones activas con sistemas externos.

•       Conectividad desde los sitios principales (oficinas, plantas, sucursales).

•       Estado de los jobs automáticos y procesos batch nocturnos.

Lo que no se valida en esta ventana se convierte en un problema que aparece durante el horario pico del día siguiente.

2. Monitoreo reforzado durante las primeras 72 horas

El comportamiento del entorno productivo durante los primeros tres días no es representativo del comportamiento normal. Los usuarios aún están adaptándose, los patrones de carga cambian, y problemas menores que no aparecieron en las pruebas emergen en producción real.

Durante este período hay que mantener:

•       Monitoreo activo de performance de las bases de datos (tiempos de respuesta, uso de CPU, I/O).

•       Revisión manual de los logs de error al menos dos veces por día.

•       Canal de comunicación directo con el equipo técnico (no solo a través de tickets).

•       Capacidad de rollback documentada y probada, aunque la expectativa sea no usarla.

3. Validación de integraciones y procesos batch

Las integraciones con sistemas externos y los procesos batch son los que más frecuentemente fallan después del cut-over. No porque estén mal diseñados, sino porque en las pruebas previas se valida que funcionen, no que funcionen bajo las condiciones exactas del entorno productivo.

Las áreas de mayor riesgo:

•       Jobs que corren de madrugada y que nadie monitorea hasta que alguien reporta un problema al día siguiente.

•       Integraciones con sistemas que no participaron activamente en las pruebas.

•       Procesos de carga masiva de datos con ventanas de tiempo ajustadas.

•       Conexiones a bases de datos externas que pueden tener configuraciones de firewall distintas.

Cada uno de estos debe tener un responsable nombrado y un criterio claro de qué hacer si falla.

4. Ajuste de sizing y configuración

Es normal que la arquitectura definida en el Blueprint requiera ajustes menores después de ver el comportamiento real en producción. El entorno de pruebas, por más bien armado que esté, no replica exactamente la carga del mundo real.

Los ajustes más frecuentes en las primeras semanas:

•       Parámetros de memoria de la base de datos (SGA, PGA).

•       Configuración de conexiones concurrentes.

•       Sizing de storage según el crecimiento real observado.

•       Ajuste de políticas de backup según el tiempo de ventana disponible.

Estos ajustes no son errores de diseño. Son el comportamiento esperado de cualquier migración bien ejecutada.

5. Documentación operativa actualizada

Después del go-live, el equipo que va a operar el entorno necesita documentación que refleje la realidad, no la planificación original. Hay siempre diferencias entre lo que se diseñó y lo que finalmente se implementó.

Lo mínimo que debe quedar documentado:

•       Arquitectura final tal como quedó (as-built).

•       Procedimientos de monitoreo diario.

•       Runbook de troubleshooting para los problemas más probables.

•       Procedimientos de backup y restore validados.

•       Contactos de soporte y escalamiento.

Sin esta documentación, el equipo opera de memoria. Y la memoria falla en los momentos de mayor presión.

6. Capacitación operativa del equipo

Hay una diferencia fundamental entre saber ejecutar una migración y saber operar un entorno Oracle en la nube. Muchos equipos tienen experiencia sólida en on-premise y llegan al go-live con conocimiento insuficiente de las particularidades del entorno cloud.

Las brechas más frecuentes que aparecen después del cut-over:

•       Cómo interpretar las métricas de OCI vs las métricas a las que estaban acostumbrados.

•       Cómo gestionar el sizing y el costo en tiempo real.

•       Cómo operar Data Guard en el nuevo entorno.

•       Cómo escalar recursos ante picos de demanda.

Esta capacitación idealmente empieza antes del go-live, pero si no ocurrió, las primeras semanas en producción son la oportunidad.

7. Cierre formal del proyecto y lecciones aprendidas

Este punto se saltea con más frecuencia de lo que debería. Cuando el go-live sale bien, el equipo se dispersa, los recursos se reasignan y nadie documenta qué funcionó, qué falló y qué se haría diferente.

Un cierre formal bien hecho toma entre 2 y 4 horas y produce:

•       Registro de decisiones técnicas tomadas durante la ejecución.

•       Lista de lo que no se cumplió según el Blueprint y por qué.

•       Identificación de riesgos que se materializaron y cómo se resolvieron.

•       Recomendaciones para migraciones futuras.

Este documento tiene valor estratégico real si la empresa tiene más bases por migrar o si en el futuro hay que justificar decisiones tomadas.

Parte 2 — Los errores más frecuentes después del cut-over

Error 1: Dar el proyecto por cerrado demasiado pronto

Es el error más común y el más costoso. El cut-over salió bien, nadie reportó problemas en las primeras horas, y el proyecto se declara terminado. Los recursos se liberan, el equipo de QA o acompañamiento se retira, y el monitoreo vuelve a niveles normales.

Lo que suele pasar después:

•       Un proceso batch que corre mensualmente falla la primera vez que se ejecuta en producción.

•       Una integración que no se probó suficientemente presenta problemas bajo carga real.

•       El equipo operativo enfrenta una situación que no sabe resolver sin el respaldo técnico del proyecto.

El proyecto debería considerarse cerrado cuando el entorno opera estable bajo carga real durante al menos dos semanas completas, no cuando el go-live termina sin incidentes.

Error 2: No tener un criterio claro para el rollback

El plan de rollback se diseña antes del cut-over. Pero en el post-cutover aparece una pregunta diferente: ¿cuándo se activa? ¿Quién toma esa decisión? ¿Con qué criterio?

Es frecuente encontrar equipos que tienen el procedimiento de rollback documentado, pero no tienen definido el umbral que lo dispara. Eso genera discusiones en el momento de mayor presión, cuando menos tiempo hay para deliberar.

Antes del go-live deben estar definidos:

•       Los indicadores que activan el rollback (por ejemplo: más de X usuarios afectados, más de Y minutos de downtime no planificado, inconsistencia de datos en sistemas críticos).

•       La persona con autoridad para tomar la decisión.

•       El tiempo máximo para tomar esa decisión desde que se detecta el problema.

Error 3: Subestimar el impacto en el equipo operativo

Hay una diferencia entre el equipo que ejecutó la migración y el equipo que va a operar el entorno el resto del año. A veces son las mismas personas, pero con roles completamente diferentes.

El equipo de operaciones necesita:

•       Conocer el entorno tal como quedó, no como estaba diseñado.

•       Tener acceso a los procedimientos operativos actualizados.

•       Saber a quién escalar y con qué información.

•       Haber practicado al menos una vez las operaciones más críticas (backup, restore, failover).

Cuando esto no ocurre, el equipo operativo improvisa. Y la improvisación en entornos Oracle productivos es cara.

Error 4: No revisar el licenciamiento después del go-live

El análisis de licenciamiento se hace durante el diagnóstico. Pero la arquitectura que termina en producción no siempre es idéntica a la que se diseñó. Ajustes de sizing, cambios de instancia, decisiones tomadas durante la ejecución pueden alterar el estado del licenciamiento.

Una revisión de licenciamiento post-go-live, aunque tome pocas horas, puede identificar:

•       Uso de features Oracle que requieren opciones no licenciadas

•       Configuraciones que no cumplen con los requisitos de BYOL

•       Cambios en el conteo de processors que afectan el costo

Este punto es especialmente relevante si se realizaron ajustes de arquitectura durante la ejecución que no estaban en el Blueprint original.

Error 5: No aprovechar las primeras semanas para capacitar

Las primeras semanas post-go-live son el mejor momento para capacitar al equipo operativo. El entorno es nuevo, las motivaciones para aprender son altas y los problemas que van apareciendo son el mejor material pedagógico disponible.

Los equipos que no aprovechan esta ventana suelen operar durante meses con brechas de conocimiento que eventualmente se convierten en incidentes.

Error 6: Ignorar las alertas menores

Durante las primeras semanas aparecen alertas y comportamientos menores que no impactan la operación inmediata. Errores en logs que no generan problemas visibles. Procesos que terminan en más tiempo del esperado. Jobs que se completan, pero con advertencias.

Estos indicadores no son irrelevantes. Son señales de que algo en el entorno no está funcionando exactamente como debería. Ignorarlos porque no están causando problemas visibles es una de las formas más seguras de llegar a un incidente mayor en el peor momento posible.

Conclusión

El cut-over es el hito más visible de una migración Oracle. Pero la diferencia entre un proyecto que realmente terminó bien y uno que simplemente no explotó todavía se define en lo que pasa después.

Las organizaciones que salen mejor de una migración son las que tratan el post-cutover con la misma disciplina que el go-live: con criterios claros, responsables definidos, monitoreo activo y documentación actualizada.

Si estás en la etapa de planificación de una migración Oracle o acabás de salir de un go-live y querés revisar el estado del entorno, puedo ayudarte a evaluar qué está resuelto y qué todavía representa un riesgo.