Checklist de migración de Oracle a OCI: 40 verificaciones antes, durante y después del corte

Una migración a Oracle Cloud Infrastructure no falla el día del corte. Falla tres semanas antes, cuando nadie preguntó qué integraciones dependen de una IP fija, o cuando se eligió Data Pump para una base de 4 TB con una ventana de seis horas. Esta lista reúne lo que verificamos en cada proyecto, en el orden en que importa. Úsala como guion de trabajo, no como formalidad.

Fase 0: antes de decidir

1. Define por qué migras. Fin de vida del hardware, costo, continuidad, un proveedor que lo exige. La razón determina las prioridades: si es costo, el diseño se optimiza distinto que si es continuidad.

2. Define RTO y RPO con el negocio, por sistema. “Cero downtime” sin presupuesto para GoldenGate no es un requisito, es un deseo. Escríbelos y fírmalos.

3. Inventaría todo lo que toca la base. Aplicaciones, interfaces, jobs externos, reportes, ETL, herramientas de monitoreo, respaldos, usuarios con conexión directa. El 80 % de los problemas post-migración viene de algo que no estaba en el inventario.

4. Revisa el licenciamiento. Tus licencias Oracle on-premise pueden usarse en OCI (BYOL) y reducen el costo de Base Database Service a una fracción. Verifica edición, opciones (Partitioning, Diagnostics Pack, RAC) y número de procesadores. En OCI se cuenta por OCPU, no por core físico.

5. Mide el tamaño real. Tamaño de datos (no del datafile: DBA_SEGMENTS), tasa de generación de redo por hora en pico (V$ARCHIVED_LOG), y ancho de banda real hacia internet. Esos tres números deciden el método de migración.

Fase 1: arquitectura destino

6. Diseña compartimentos por ambiente y por sensibilidad (producción, no producción, red compartida). Las políticas IAM se aplican por compartimento; una tenancy plana es imposible de auditar.

7. Diseña la VCN con subredes privadas para base de datos y aplicaciones, y una subred pública solo para el balanceador y, si no hay otra opción, el bastión. La base de datos nunca tiene IP pública.

8. Usa OCI Bastion o un host de salto en lugar de abrir SSH/1521 a internet. Con listas de seguridad que limiten el origen.

9. Define la conectividad híbrida. VPN Site-to-Site basta para la mayoría; FastConnect si necesitas latencia predecible o mover decenas de TB con regularidad. Prueba la VPN antes de la migración, no durante.

10. Elige el servicio de base de datos. Base Database Service (VM) para control total, Exadata Cloud para cargas pesadas, Autonomous cuando la aplicación lo tolera (sin acceso a SO, sin algunos features). Para Forms/ERP legacy, Base DB en VM es lo habitual.

11. Dimensiona por carga real, no por el servidor actual. Un servidor on-premise de 32 cores que usa 20 % de CPU no necesita 32 OCPU. Usa AWR del último mes para dimensionar y deja margen para crecer con un clic.

12. Diseña la alta disponibilidad. Data Guard entre dominios de disponibilidad (o regiones) para producción. Define desde el inicio si el standby estará activo (Active Data Guard, con licencia) o solo en recuperación.

13. Diseña los respaldos. Respaldo automático de OCI a Object Storage con retención definida, más una copia RMAN en Object Storage de otra región si el RPO de desastre lo exige. Verifica que puedas restaurar antes de dar por cerrado el diseño.

14. Define la gestión de secretos. Contraseñas de base de datos, wallets y llaves en OCI Vault, no en archivos de configuración.

15. Planifica los servidores de aplicaciones. WebLogic y Forms van en instancias de cómputo o en OCI Marketplace (imágenes con licencia incluida o BYOL). Mismo criterio de red: subred privada, balanceador delante.

16. Diseña el balanceador de carga de OCI con certificado SSL propio y health checks reales (una URL de la aplicación, no solo el puerto).

17. Presupuesta con la calculadora de OCI y añade Object Storage, salida de datos a internet (egress) y respaldos. Configura presupuestos y alertas de consumo desde el primer día.

Fase 2: método de migración

18. Elige el método según tamaño, ventana y plataforma origen:

Método	Cuándo	Downtime típico
Data Pump (expdp/impdp)	Bases pequeñas o medianas (< 500 GB), ventana amplia, cambio de plataforma o versión	Horas
RMAN duplicate / restore	Misma plataforma y endianness, base mediana o grande	Horas
Transportable Tablespaces	Cambio de endianness (AIX → Linux) en bases grandes	Horas, menor que Data Pump
Data Guard (physical standby en OCI)	Misma plataforma, base grande, ventana corta	Minutos
GoldenGate	Cambio de plataforma o versión con ventana mínima, o migración por fases	Minutos
Zero Downtime Migration (ZDM)	Orquesta Data Guard o GoldenGate con automatización de Oracle	Minutos

19. Si migras desde IBM AIX o Solaris SPARC, recuerda que el endianness cambia: no sirven RMAN restore ni Data Guard físico directos. Es Data Pump, Transportable Tablespaces con conversión, o GoldenGate.

20. Verifica compatibilidad de versión. Si subes de 11g/12c a 19c en la misma migración, decide si lo haces en origen (upgrade primero) o en destino (importar en 19c). Hacerlo en destino es más limpio pero obliga a probar la aplicación contra 19c antes.

21. Prueba el ancho de banda real transfiriendo un archivo de 50 GB a Object Storage. Extrapola. Si no alcanza para la ventana, usa OCI Data Transfer Appliance o GoldenGate.

22. Define el plan de reversa por escrito. Qué se hace si a las 03:00 del corte algo no cumple el criterio go: volver al origen (que no debe haberse tocado), reapuntar DNS, informar. Con responsables y tiempos.

Fase 3: ensayo

23. Ejecuta una migración completa de prueba en el ambiente destino, cronometrada paso a paso. Es la única fuente de tiempos reales para el plan de corte.

24. Valida la aplicación en destino con usuarios clave de cada módulo: facturación, inventario, contabilidad, reportes. Con casos de prueba escritos y resultado esperado.

25. Compara rendimiento. AWR de un periodo representativo en origen contra el mismo escenario en destino. Si el destino es más lento, corrígelo antes del corte: dimensionamiento, parámetros, tipo de almacenamiento (Block Volume performance tier).

26. Prueba las integraciones una por una: interfaces con bancos, SRI/facturación electrónica, ERP, ETL, impresoras de red, correo. Cada una tiene una IP, un certificado o una ruta que cambia.

27. Prueba el respaldo y la restauración en destino. Restaura a un punto en el tiempo.

28. Prueba el failover de Data Guard si lo configuraste. Switchover ida y vuelta.

29. Ajusta el plan de corte con los tiempos reales y repite el ensayo si cambiaste algo relevante.

Fase 4: corte

30. Congela cambios en origen desde una semana antes: sin parches, sin nuevos objetos, sin cambios de configuración.

31. Comunica la ventana al negocio con fecha, hora de inicio, hora estimada de fin y hora límite para decidir reversa.

32. Reduce el TTL del DNS a 5 minutos al menos 24 horas antes, para que el cambio de IP propague rápido.

33. Checklist impreso con casillas y responsable por paso. Cada paso con criterio de éxito. Puntos go/no-go explícitos.

34. Respaldo final del origen antes de empezar, verificado.

35. Detén la aplicación en origen, sincroniza la última diferencia (último archive log, último trail de GoldenGate, último export incremental según el método).

36. Valida en destino antes de abrir a usuarios: conteo de objetos inválidos (DBA_OBJECTS con STATUS='INVALID'), secuencias con el valor correcto, jobs programados, usuarios y permisos, enlaces de base de datos, directorios externos.

37. Reapunta DNS y balanceadores, abre a un grupo piloto de usuarios y luego a todos.

38. No apagues el origen. Déjalo intacto, sin recibir transacciones, durante al menos una semana.

Fase 5: estabilización

39. Monitoreo intensivo durante la primera semana: alert log, esperas, consumo de OCPU, latencia del balanceador, costos diarios. Ajusta lo que aparezca.

40. Cierre formal: documento de arquitectura final, runbook de operación en OCI, inventario de accesos, calendario de respaldos y parches, revisión de costo real contra presupuesto. Solo entonces se apaga el origen.

---

Esta lista sale de migraciones reales: una de ellas, la de toda la infraestructura de una empresa de retail a OCI, con bases de datos, WebLogic y balanceadores. Si estás evaluando una migración, una evaluación de arquitectura te entrega el método, la ventana realista y el presupuesto antes de comprometerte.