¿Cómo planificas una migración cloud?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Una migración empieza con un inventario que mapea cada aplicación, sus dependencias, flujos de datos y dueños, porque las sorpresas viven en las conexiones. Cada aplicación se clasifica: mover tal cual, replataformar sobre servicios gestionados, refactorizar, sustituir por SaaS o retirar. Los requisitos de seguridad, residencia de datos, disponibilidad y coste se definen por aplicación antes de cualquier movimiento. Primero se construye una landing zone con cuentas, redes, identidad y salvaguardas. La migración avanza por oleadas empezando por una aplicación de bajo riesgo y autocontenida para probar las herramientas y el runbook, cada oleada validada contra sus requisitos, con rollback disponible hasta que la validación pasa y el desmantelamiento programado para que el entorno antiguo deje de costar dinero.

Ejemplo

Una empresa con 120 aplicaciones hizo un descubrimiento de seis semanas que encontró 30 integraciones sin documentar. La primera oleada movió una wiki interna y un job de informes por lotes, lo que expuso un error de corte de DNS en el runbook sin coste para clientes. La segunda oleada replataformó el portal de clientes sobre Kubernetes gestionado y una base de datos gestionada con dos semanas de ejecución en paralelo; el entorno on-premise se desmanteló solo tras un mes de datos de SLO limpios.

Errores frecuentes

• Migrar primero el sistema más crítico para demostrar compromiso.
• Mover todo tal cual sin plan para usar servicios gestionados después.
• Dejar el antiguo centro de datos un año en marcha porque nadie era dueño del desmantelamiento.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.