Estrategias de migración a la nube: las 7 R, descubrimiento, oleadas y cutover

La mayoría de los programas de migración no se retrasan por la tecnología. Copiar una máquina virtual, replicar una base de datos y redirigir el DNS son mecánicas bien conocidas y con herramientas de sobra. Lo que falla es que nadie sabe decir con seguridad cuáles de las cuatrocientas aplicaciones del inventario siguen importando, de quién son, con qué se comunican o qué pasa si una de ellas se detiene durante seis horas. Una migración es un ejercicio de gestión de cartera disfrazado de proyecto de ingeniería.

Esta guía sigue la secuencia que recorre un programa real: descubrir lo que tienes, decidir una estrategia para cada aplicación, construir el destino, mover los datos, hacer el cutover y repetir por oleadas. Da por hecho que conoces los fundamentos de la nube y, si el destino es Azure, la jerarquía descrita en los fundamentos de Azure.

Descubrimiento: saber qué ejecutas realmente

El descubrimiento responde a tres preguntas por aplicación: qué es, de qué depende y cuánto cuesta mantenerla funcionando tal como está.

Las herramientas automatizadas te dan la primera pasada. Los escáneres sin agente leen los inventarios de los hipervisores y los flujos de red; los recolectores con agente añaden detalle a nivel de proceso e historial de rendimiento. Tanto AWS como Azure ofrecen servicios de evaluación de migraciones que recomiendan un destino bien dimensionado a partir de varias semanas de uso observado de CPU, memoria, disco y red. Tómate en serio ese historial de rendimiento: es el artefacto más valioso que produce el descubrimiento, porque es la única defensa contra volver a aprovisionar en la nube un parque dimensionado para el pico.

La automatización no te dirá lo que realmente decide el plan: quién aprueba el tiempo de inactividad, qué contrato con un proveedor prohíbe ejecutar fuera de un centro de datos concreto, qué base de datos es discretamente el sistema de registro de un informe regulatorio. Eso sale de entrevistas, y el resultado es una ficha de cartera por aplicación:

El mapeo de dependencias es donde se esconde el riesgo real. Los datos de flujo revelan las conexiones que nadie documentó: un fichero que se deja cada noche en un recurso compartido SMB, una dirección IP escrita a fuego en un proceso batch, una herramienta de informes que mantiene abierta una conexión contra una réplica de producción. Construye el mapa a partir del tráfico observado durante al menos un mes completo, para que aparezcan los procesos trimestrales y de fin de mes, y agrupa después las aplicaciones en grupos de migración (move groups): conjuntos que deben moverse juntos porque separarlos llevaría un diálogo muy verboso y sensible a la latencia a través de un enlace de red.

Las siete R

Una vez que sabes qué es una aplicación, le asignas una estrategia. La lista empezó con cinco y hoy, por convención, son siete.

Retire (retirar). Apagarla. En la mayoría de los parques, entre el diez y el veinte por ciento de las aplicaciones no tienen usuarios o duplican otra cosa. Cada retirada elimina coste de migración, coste de licencias y superficie de ataque. Es la opción con mayor retorno y la que más cuesta conseguir que te aprueben, porque alguien tiene que aceptar el riesgo de equivocarse.

Retain (mantener). Dejarla donde está, por ahora. Se justifica por una dependencia del mainframe, una sustitución inminente, un regulador que aún no ha aprobado la región de destino o un hardware que todavía no se ha amortizado. Mantener debe llevar una fecha de revisión; si no, se convierte en un centro de datos permanente con tres servidores dentro y un contrato de soporte completo.

Rehost (realojar). Mover la carga tal cual: el famoso «lift and shift». Las herramientas de replicación a nivel de bloque copian servidores en ejecución a máquinas virtuales en la nube con minutos de inactividad en el cutover. Es rápido, de bajo riesgo y no exige cambios en la aplicación; también arrastra todas las ineficiencias, así que un parque realojado suele costar más por unidad de trabajo que el hardware que dejó atrás hasta que se optimiza.

Replatform (cambiar de plataforma). Moverla con cambios concretos que aportan un beneficio desproporcionado: el «lift and reshape». Movimientos típicos: apuntar la aplicación a una base de datos gestionada en lugar de una administrada por ti, ponerla detrás de un balanceador de carga gestionado con certificados gestionados, contenerizarla sin rediseñarla o cambiar un recurso compartido de ficheros por almacenamiento de objetos. La lógica de la aplicación no se toca; la carga operativa se desploma. En la mayoría de los parques es la mejor opción por defecto cuando ninguna fecha límite obliga al rehost.

Repurchase (recomprar). Sustituirla por un producto comercial, normalmente SaaS. Habitual en CRM, RR. HH., ticketing, colaboración y correo. El trabajo de migración pasa a ser migración de datos, integración y gestión del cambio en lugar de infraestructura, y el coste total suele estar dominado por las dos últimas.

Refactor (refactorizar). Reescribir partes importantes para usar servicios cloud nativos y, a menudo, cambiar la arquitectura: descomponer un monolito, pasar a procesamiento orientado a eventos, ir a serverless. Aporta el mayor beneficio a largo plazo y consume el mayor presupuesto y a las personas más sénior. Resérvalo para aplicaciones con un business case concreto: un sistema que no puede escalar para un plan de crecimiento conocido, o uno cuyo lead time de cambios está frenando ingresos. Refactorizar con una fecha límite de salida del centro de datos encima es la forma en que los programas incumplen sus plazos.

Relocate (reubicar). Mover un parque de virtualización entero a una versión alojada en la nube de la misma pila de hipervisor, sin convertir las máquinas una a una. Resulta atractivo cuando un gran parque VMware tiene que salir de un edificio deprisa y el esfuerzo de conversión es inasumible; conserva las herramientas y las competencias, y aplaza en lugar de resolver la cuestión de la modernización.

Elegir una estrategia para cada aplicación

Una heurística práctica, que se aplica aplicación por aplicación y luego se contrasta con la cartera completa:

Is anyone using it?                          no  -> Retire
Is there a credible SaaS equivalent?         yes -> Repurchase
Is it blocked (licence, latency, regulator)? yes -> Retain (with review date)
Is change lead time or scale a real problem
   AND is there budget and appetite?         yes -> Refactor
Would swapping 1-2 components remove most
   of the operational burden?                yes -> Replatform
Is the deadline immovable?                   yes -> Rehost, optimise later
Is the estate large and time short?          yes -> Relocate

Dos comprobaciones a nivel de cartera importan más que la respuesta aplicación por aplicación. Primero, la mezcla: un plan con un noventa por ciento de rehost cumplirá la fecha y decepcionará a todos en costes, mientras que un plan con un treinta por ciento de refactor no cumplirá la fecha en absoluto. Algo así como un sesenta por ciento de rehost y replatform, entre un diez y un quince por ciento de retiradas y un puñado de refactors elegidos por su impacto en el negocio es una forma que suele sobrevivir al contacto con la realidad. Segundo, la secuenciación: pon los refactors en una vía aparte con su propia financiación, para que una reescritura que se retrasa no bloquee la salida de un centro de datos.

Primero la landing zone

No debería moverse nada hasta que el destino esté listo para recibirlo con seguridad. Una landing zone es la base preconstruida y automatizada en la que aterriza cada carga migrada. Los dos grandes proveedores publican implementaciones de referencia, y construir la tuya a partir de una de ellas es mucho más barato que inventarla.

Como mínimo, proporciona:

• Estructura de cuentas o suscripciones con límites separados para producción, no producción, servicios compartidos de plataforma, herramientas de seguridad y archivo de logs.
• Integración de identidades: federación con el directorio corporativo, grupos asignados a roles, nada de credenciales de larga duración, cuentas de emergencia (break-glass) documentadas y con alarmas.
• Topología de red: hub-and-spoke o equivalente, rangos de direcciones asignados para que no colisionen con los on-premises, conectividad de vuelta al centro de datos mediante circuito privado o VPN, resolución DNS funcionando en ambos sentidos.
• Barreras de protección (guardrails): políticas que impiden crear recursos en regiones no aprobadas, exigen cifrado y etiquetado, y bloquean por defecto el almacenamiento público. Controles preventivos, no un informe que se publica cada mes.
• Logging y monitorización: logs de auditoría centralizados escritos en una cuenta que nadie más puede modificar, más una plataforma de monitorización a la que se conectan las cargas en lugar de que cada una se invente la suya.
• Un pipeline y plantillas, para que aterrizar una carga signifique ejecutar automatización, no hacer clics. Es la parte del programa en la que más rinde la disciplina de la infraestructura como código.

El DNS híbrido y los rangos IP solapados merecen mención aparte: son aburridos, se descubren tarde y han retrasado más migraciones que cualquier problema de aplicación.

Mover los datos

Los datos son la parte que no se puede rehacer rápido, así que son ellos los que marcan el diseño del cutover.

Transferencia masiva. Para grandes conjuntos de datos estáticos, haz las cuentas con honestidad: un terabyte por un enlace de un gigabit saturado tarda unas tres horas a la velocidad teórica de línea y bastante más en la práctica, y los parques que se miden en cientos de terabytes no caben en la ventana. Los dispositivos de transferencia física —equipos robustos que te envían, llenas y devuelves— existen exactamente para esto y suelen ser más rápidos y baratos que ampliar un circuito para una operación puntual.

Replicación continua. Para bases de datos, el patrón estándar es un servicio de replicación que hace una carga completa y después aplica los cambios continuos desde el log de transacciones hasta que origen y destino están sincronizados. AWS Database Migration Service y Azure Database Migration Service lo hacen ambos, incluidas las migraciones heterogéneas en las que cambia el motor, con un paso previo de conversión de esquema. Mantén la replicación en marcha varios días antes del cutover para que el retardo esté medido, no supuesto.

Validación. Contar filas es el principio, no el final. Compara checksums por tabla, concilia un total a nivel de negocio (el importe de los pedidos de ayer, el balance de comprobación) y ejecuta las rutas de lectura de la propia aplicación contra el destino antes de que nadie se comprometa.

El enfoque de migración adopta entonces una de estas tres formas:

La ejecución en paralelo —ambos sistemas activos, uno de ellos como fuente de verdad— es la más segura y la más cara, porque alguien tiene que conciliar los dos y decidir qué pasa cuando no coinciden.

Oleadas, cutover y rollback

Las migraciones avanzan por oleadas: lotes de grupos de migración planificados juntos. La primera oleada es un piloto y su finalidad es aprender, no mover volumen. Elige dos o tres aplicaciones reales, con responsable y lo bastante poco importantes como para que un mal fin de semana sea soportable, e instrumenta el propio proceso: cuánto tardó cada paso, en qué se equivocaba el runbook, qué permisos faltaban.

Cada oleada posterior debe tener criterios de entrada por escrito (landing zone lista, aprobación del responsable, dependencias ya migradas o en la misma oleada), un runbook con responsables con nombre y tiempos, y criterios de salida explícitos: tasas de error y latencia dentro de una banda acordada, procesos batch completados con éxito, conciliación limpia, monitorización alertando correctamente.

El plan de rollback es lo que permite intentar todo esto sin jugársela, y debe ser más concreto que «volvemos atrás». Deja por escrito el punto de no retorno —normalmente el momento en que el destino acepta escrituras que no se replican de vuelta— y cómo es la decisión a cada lado de ese punto. Antes de él, el rollback consiste en redirigir el DNS o un balanceador de carga al origen. Después, significa replicación inversa o reproducir transacciones, algo que hay que haber probado si pretendes afirmar que existe.

Justo después de cada oleada, haz dos cosas que los programas se saltan con frecuencia: da de baja el origen, porque pagar ambos parques es el sobrecoste clásico; y redimensiona el destino a partir de dos semanas de métricas reales en la nube en lugar de la estimación on-premises, que es de donde salen de verdad los ahorros que financiaron el programa. Consulta la gestión de costes en la nube.

Riesgos que conviene nombrar en el plan

Regresiones de rendimiento por arquitecturas partidas. Durante una migración, es frecuente que una aplicación en la nube hable con una base de datos que sigue on-premises. Una conversación que antes tardaba microsegundos ahora cuesta milisegundos por ida y vuelta, y el código ORM verboso se degrada de forma no lineal. Mueve los componentes acoplados en la misma oleada.

Licencias ligadas al hardware. Algunos fabricantes cobran por núcleo físico o prohíben el alojamiento virtualizado. Compruébalo antes de diseñar el destino, no después.

Integraciones sin documentar que se disparan cada trimestre. Un mes de datos de flujo no capta el proceso de cierre de año. Pregunta a finanzas y a operaciones qué ocurre en los cierres de periodo.

La cola sin responsable. Las aplicaciones sin un responsable identificable no se pueden retirar ni migrar. Escálalas pronto, con una opción por defecto anunciada —normalmente «la apagaremos en esta fecha salvo que alguien la reclame»—, porque la alternativa es descubrir al responsable en la semana cincuenta.

Competencias y cansancio. Los cutovers se hacen en fin de semana. Un calendario que da por hecho que los mismos seis ingenieros pueden encadenar doce fines de semana seguidos es un plan para perderlos a mitad del programa.

Puntos clave

• Es el descubrimiento, no la tecnología, lo que determina si una migración sale bien: fichas de cartera, uso observado y un mapa de dependencias construido con al menos un mes de tráfico.
• Las siete R —retire, retain, rehost, replatform, repurchase, refactor, relocate— se asignan aplicación por aplicación, y la mezcla de la cartera decide si el programa cumple su fecha.
• Retirar las aplicaciones muertas es la victoria más barata que existe, y el rehost es legítimo siempre que el trabajo de optimización esté planificado y no se dé por supuesto.
• La landing zone —cuentas, identidad, red, guardrails, logging, pipelines— tiene que existir antes de que se mueva la primera carga.
• El enfoque de migración de datos se deriva del tiempo de inactividad aceptable; valida con una conciliación a nivel de negocio, no contando filas.
• Las oleadas necesitan criterios de entrada y de salida, un punto de no retorno con nombre, un rollback ensayado y la baja inmediata del origen para dejar de pagar dos veces.