Modernizar aplicaciones: strangler fig, mainframes y AWS Transform

Mover una aplicación a EC2 tal cual (rehost) la saca del centro de datos, pero no la vuelve más fácil de cambiar. El monolito sigue siendo un monolito, ahora en la nube. Modernizar es cambiar la aplicación por dentro para desplegar más seguido, escalar por partes y pagar menos licencias. Reescribir todo de una vez casi siempre sale mal: años sin entregar nada, y un día de corte con todo el riesgo junto. Las estrategias de migración (las 7 R) están en migrar a AWS.

Caminos de modernización

El patrón strangler fig, paso a paso

1. 1

   Pon una fachada delante

   Un punto de entrada que hoy manda todo al monolito: API Gateway o un ALB con reglas por ruta. Los clientes no notan el cambio, pero ya puedes desviar rutas.
2. 2

   Elige la primera capacidad

   Algo con valor visible, pocas dependencias y bajo riesgo: el catálogo de productos antes que los pagos. Sirve para aprender el proceso.
3. 3

   Construye el servicio nuevo

   Con su propio código, su propio despliegue y, a su tiempo, sus propios datos. Corre en paralelo con el monolito.
4. 4

   Desvía el tráfico de a poco

   Una regla de ruta manda /catalogo al servicio nuevo. Con grupos de destino ponderados del ALB empiezas con el 5 % y comparas errores y latencia.
5. 5

   Retira la parte vieja

   Con el 100 % del tráfico en el servicio nuevo, borra ese código del monolito. Si no lo borras, no modernizaste: duplicaste.
6. 6

   Repite hasta apagar el monolito

   Capacidad por capacidad. Al final retiras el monolito y simplificas las reglas de la fachada.

Cortar el monolito: capacidades, capa anticorrupción y datos

Divide por capacidad de negocio, no por capa técnica. «Catálogo», «pedidos» y «facturación» son buenos cortes; «la capa de base de datos» o «el frontend» no, porque cada cambio de negocio tocaría todos los servicios.

El monolito y el servicio nuevo hablan idiomas distintos: el viejo llama «cliente» a un registro con cuarenta campos y códigos de los noventa; el nuevo tiene un modelo limpio. La capa anticorrupción (anti-corruption layer) traduce entre los dos modelos para que el nuevo no herede los vicios del viejo. Es temporal: se retira cuando ya nadie depende del modelo viejo.

La extracción por eventos reduce el acoplamiento. El monolito publica un evento cuando algo cambia, como PedidoCreado, en EventBridge, y el servicio nuevo construye su propia copia de los datos que necesita. Si no puedes tocar el código del monolito, captura los cambios de su base con DMS (CDC) y conviértelos en eventos.

Mainframes

Los mainframes corren sistemas críticos en COBOL, PL/I y JCL, con décadas de reglas de negocio que pocos entienden completas. Hay cuatro caminos:

AWS Mainframe Modernization ofrecía entornos para replatform y refactor, administrados o autoadministrados. Hoy ninguna de sus dos experiencias acepta clientes nuevos; los clientes existentes siguen. Para proyectos nuevos, AWS dirige a AWS Transform for mainframe y a ofertas directas de los proveedores.

Qué automatiza AWS Transform

AWS Transform es un servicio con agentes de IA especializados que automatizan el trabajo pesado de migrar y modernizar: análisis, planeación, conversión de código y pruebas. Un equipo revisa y aprueba cada etapa en un espacio de trabajo compartido.

• 

  AWS Transform for mainframe

  Analiza COBOL, PL/I y JCL, mapea dependencias, extrae reglas de negocio, refactoriza a Java o C#, migra datos de VSAM, IMS o Db2 y genera pruebas de equivalencia.
• 

  AWS Transform for Windows

  Lleva .NET Framework a .NET 8 o superior en Linux, migra SQL Server a Aurora PostgreSQL u otros motores, actualiza interfaces como Web Forms y pasa despliegues de IIS a contenedores.
• 

  AWS Transform for migrations

  Antes «for VMware». Descubre servidores de VMware, Hyper-V u otras fuentes, planea olas, recomienda una de las 7 R por servidor, convierte la red a VPC y orquesta el corte.
• 

  AWS Transform custom

  Transformaciones de código a escala: actualizar versiones de Java, Python o Node.js, pasar del AWS SDK v1 al v2 o recetas propias en lenguaje natural sobre muchos repositorios.
• 

  AWS Transform MGN

  El nuevo nombre de AWS Application Migration Service desde junio de 2026. Replica servidores y los lanza en EC2; es el motor de rehost que usa AWS Transform.

Medir el avance y el riesgo

• Avance: porcentaje del tráfico que atienden los servicios nuevos y capacidades retiradas del monolito, no líneas de código escritas.
• Velocidad de entrega: frecuencia de despliegue y tiempo desde el commit hasta producción, antes y después.
• Estabilidad: tasa de cambios que fallan y tiempo de recuperación. Si empeoran, frena y corrige.
• Costo: mientras conviven, pagas los dos sistemas. Fija una fecha para apagar cada parte vieja.
• Riesgo: cada desvío de tráfico tiene vuelta atrás en la fachada; prueba esa vuelta antes de necesitarla.