Migrar cientos de aplicaciones heredadas en VM a AWS funciona cuando se gestiona como una cadena de producción y no como cientos de proyectos aislados: inventariar y clasificar cada app, decidir app por app entre actualizar o reconstruir y dividir el parque en bloques a cargo de equipos pequeños. Un esqueleto de aplicación común, unos pasos de conmutación y de vuelta atrás probados y unos manuales de operaciones que cualquier equipo pueda seguir mantienen la calidad estable a medida que crece el volumen.
Empiece por un inventario que muestre lo que de verdad necesita cada app
Antes de que nadie toque AWS, liste todas las aplicaciones que se ejecutan en las VM heredadas y anote los datos que determinan el esfuerzo de migración. Al principio basta con una hoja de cálculo compartida. Lo importante es que cada app tenga una fila, un responsable y las mismas columnas.
Después, clasifique cada app en un número reducido de vías, como actualizar, reconstruir y retirar. Así los equipos pueden planificar por vía en lugar de debatir cada app desde cero.
- Versión del entorno de ejecución y del framework, señalando todo lo que haya llegado al final de su vida útil
- Bases de datos, recursos compartidos de archivos y tareas programadas de las que depende la app
- Integraciones de entrada y de salida, incluidos los nombres de host y las direcciones IP escritos en el código
- Método de autenticación y cualquier secreto almacenado en la VM
- Responsable de negocio, nivel de uso y ventana de indisponibilidad aceptable
Decida app por app entre actualizar o reconstruir, no una sola vez para todo el programa
Ninguna estrategia única sirve para cientos de apps. Algunas solo necesitan actualizar el framework, externalizar la configuración y un nuevo destino de despliegue. Otras arrastran tanto código muerto o una estructura tan enmarañada que reconstruirlas sobre una base limpia es más rápido que repararlas.
Tome la decisión con criterios escritos para que equipos distintos lleguen a la misma respuesta. Una regla útil: si llevar la app al esqueleto estándar obliga de todos modos a reescribir la mayoría de sus controladores y de su acceso a datos, reconstrúyala. Si la lógica de negocio se traslada casi intacta, actualícela.
El programa de Crédit Agricole, que trasladó 600+ aplicaciones internas de VM heredadas a AWS, utilizó ambas vías. Las apps se reconstruyeron sobre el esqueleto CodeIgniter interno del banco: algunas se actualizaron y otras se rehicieron desde cero.
- Actualizar cuando el código es legible, su comportamiento está claro y la distancia con la versión del framework es pequeña
- Reconstruir cuando la lógica de negocio está mezclada con la presentación por todas partes o la app depende de funciones del lenguaje que ya se han eliminado
- Retirar cuando el uso es casi nulo y el responsable de negocio está de acuerdo, porque la migración más barata es la que no se hace
Divida el parque en bloques y asigne cada bloque a un equipo
A esta escala, un único equipo central se convierte en el cuello de botella. Un modelo por bloques asigna un lote de apps relacionadas a un equipo pequeño que se encarga de ellas desde el análisis hasta la conmutación.
Agrupe los bloques por dependencias compartidas, no por orden alfabético. Las apps que comparten una base de datos o se llaman entre sí deben migrarse juntas; si no, el mismo trabajo de integración se repite en varios equipos.
Los bloques también hacen medible el avance. Cada equipo informa de los mismos estados para cada app, como analizada, migrada, probada, pasada a producción y desmantelada, y el panel del programa es la suma de esos estados. El programa de Crédit Agricole funcionó así, y SDK Enterprises realizó 50+ de sus migraciones de aplicaciones como parte del equipo del programa.
Construya un esqueleto estándar y haga que todas las apps se asienten en él
Un esqueleto de aplicación estándar es lo que convierte cientos de migraciones en un proceso repetible. Fija las decisiones que no deberían volver a tomarse para cada app: estructura de directorios, configuración mediante variables de entorno, formato de los registros, comprobaciones de estado, puntos de enganche de la autenticación y pipeline de despliegue.
Así, cada app migrada solo se diferencia en su lógica de negocio. Los revisores saben dónde mirar, los equipos de operaciones obtienen registros y alarmas coherentes, y una corrección en el esqueleto llega a todas las apps construidas sobre él.
Mantenga el esqueleto pequeño y versionado. Si crece hasta convertirse en un framework propio, los equipos empezarán a esquivarlo.
Planifique la conmutación y la vuelta atrás antes de la primera migración
Cada app necesita un plan de conmutación que indique cómo se traslada el tráfico, cómo se trasladan los datos y cómo volver atrás. Decídalo antes de migrar la primera app. Improvisar una vuelta atrás en plena incidencia es la forma en que los programas de migración pierden la confianza del negocio.
- Ventana de congelación: acordar con el responsable de negocio cuándo se dejan de hacer cambios en la VM antigua
- Sincronización de datos: migrar los datos con antelación y hacer una sincronización final de las diferencias durante la ventana de conmutación
- Cambio de tráfico: modificar el DNS o el enrutamiento del balanceador de carga, con TTL de DNS bajos configurados días antes
- Pruebas de humo: una comprobación breve y guionizada del inicio de sesión, las pantallas clave y las integraciones justo después del cambio
- Criterio de vuelta atrás: una persona designada y condiciones escritas para volver a la versión anterior
- VM antigua conservada: detenerla, pero no borrarla hasta que la app haya funcionado sin problemas en AWS durante un periodo acordado
Escriba manuales de operaciones que cualquier equipo pueda seguir desde el primer día
Un manual de operaciones (runbook) es la lista de comprobación de una operación repetible: preparar una app, conmutarla, volver atrás, desmantelar la VM. Escriba cada uno una sola vez, pruébelo con las primeras apps y actualícelo cada vez que algo sorprenda a un equipo.
Los buenos manuales indican comandos, responsables y resultados esperados, no intenciones. «Comprobar que la app funciona» no es un paso. «Iniciar sesión como usuario de prueba y confirmar que el panel carga los datos de la cuenta» sí lo es.
Los manuales son también la forma de que los ingenieros que se incorporan a mitad de programa sean productivos enseguida. Un especialista que llega en la sexta semana debería poder conmutar una app siguiendo los documentos tras una sola sesión en pareja.
Dónde encaja un equipo externo en una gran migración
Los grandes programas suelen necesitar capacidad adicional durante un periodo definido sin ceder el control. Nos hacemos cargo de bloques de migración dentro de programas más amplios, trabajando con el esqueleto, los manuales de operaciones y las herramientas del cliente, con nuestros ingenieros y especialistas freelance seleccionados bajo un único contrato.
Puntos clave
- Haga inventario de todas las apps y clasifíquelas antes de migrar ninguna, para poder planificar el trabajo por vías.
- Elija actualizar, reconstruir o retirar app por app, con criterios escritos que todos los equipos apliquen igual.
- Divida el parque en bloques de apps relacionadas, cada uno a cargo de un equipo pequeño de principio a fin.
- Un esqueleto de aplicación pequeño y versionado hace que cientos de migraciones sean coherentes y revisables.
- No conmute nunca una app sin una vuelta atrás probada y con la VM antigua todavía disponible.
Preguntas frecuentes
¿Cuánto se tarda en migrar cientos de aplicaciones a AWS?
Depende del número de apps, de la proporción que necesita una reconstrucción, del número de equipos en paralelo y de las ventanas de conmutación que acepte el negocio. Estímelo después de la clasificación: cronometre unas pocas apps de cada vía, multiplique por el tamaño de cada vía y divida por la capacidad de los equipos.
¿Conviene hacer primero un lift and shift de las apps heredadas y modernizarlas después?
El lift and shift es lo más rápido cuando una app ya funciona sobre un entorno de ejecución con soporte y el objetivo es salir de un centro de datos. En las apps con entornos de ejecución sin soporte, trasladarlas sin cambios lleva los riesgos antiguos a la nueva plataforma, así que actualizarlas o reconstruirlas durante la migración suele salir más barato en conjunto.
¿Qué es una migración por bloques?
Una migración por bloques divide un gran parque de aplicaciones en lotes de apps relacionadas y asigna cada lote a un equipo que se encarga de él desde el análisis hasta la conmutación. Elimina el cuello de botella central y facilita el seguimiento del avance entre muchos equipos.