Modernización sin fricción: AWS Transform en acción (VMware EC2 nativo). Parte 2: Hands-on

🧠Introducción

En la Parte 1 expliqué por qué AWS Transform para VMware está cambiando la forma en que planificamos migraciones a escala: discovery, traducción de red y wave planning asistidos por IA.

En esta Parte 2 vamos a lo que más valor genera: la práctica.
El objetivo es construir un piloto reproducible para entender el flujo completo:

✅ Simular un entorno “on-prem”
✅ Cargar informacion en AWS Transform
✅ Obtener plan de migración + oleadas + diseño de red (VMware → VPC)
✅ Avanzar hacia ejecución integrando AWS MGN

👉 Preambulo

Para esta práctica no usamos un vCenter real ni un cluster ESXi físico. En su lugar, se construyó un entorno simulado de VMware dentro de AWS, utilizando instancias nativas (Amazon EC2) y componentes de infraestructura que emulan los elementos que normalmente encontraríamos en un datacenter on-prem.

La intención del lab es replicar, de forma controlada y reproducible, los insumos mínimos que típicamente se requieren para iniciar una migración VMware→AWS en un escenario real: inventario, topología, segmentación, comunicación entre workloads y un dataset tipo RVTools.

¿Qué significa “simular VMware con EC2” y por qué tiene sentido?

En migraciones reales, herramientas como AWS Transform consumen datasets provenientes de:

• RVTools exports (inventario y configuración extraída desde vCenter),

• AWS Application Discovery Service (ADS),

• Datasets equivalentes exportados desde CMDB u otras fuentes.

En este lab, la “infra VMware” se representa con workloads EC2 que simulan:

• Múltiples VMs con diferentes roles (web/app/db/servicios),

• Patrones de comunicación east-west (dependencias),

• Separación lógica por capas o dominios (segmentación/red).

Es decir: no intentaremos ejecutar VMware. Lo que haremos es construir una infraestructura “tipo on-prem” con señales equivalentes para que el pipeline de planificación (discovery → dependencias → red → waves) sea demostrable.

⚡ ¿Qué se despliega exactamente?

Para la actividad previamente, se levantara un stack automatizado (via IaC), que genera una topología reproducible.

A alto nivel, se crean:

• VPC + subnets + route tables para representar la conectividad base del “datacenter simulado”.

• Instancias EC2 que representan servidores/VMs de distintas capas (por ejemplo: front-end, back-end, data/services).

• Security Groups como equivalente funcional de reglas de segmentación (similar a lo que serían ACLs/FW rules on-prem o reglas distribuidas).

• Componentes auxiliares para pruebas de conectividad/servicios y para garantizar que exista comunicación controlada entre nodos (dependencias observables).

La idea es que, cuando generemos el dataset, tengamos un inventario “realista”: diferentes máquinas, tamaños, redes, y relaciones de consumo entre servicios.

🔧 Diagrama simple del laboratorio

¿Por qué RVTools es clave en este ejercicio?

En ambientes VMware, RVTools es uno de los mecanismos más usados para extraer inventario desde vCenter porque incluye información como:

• lista de VMs, hosts, clusters,

• CPU/Mem asignados,

• Discos y storage,

• Redes/portgroups,

• Metadatos suficientes para una primera etapa de discovery y sizing.

En este lab, generamos un export tipo RVTools a partir del entorno simulado. El resultado final es un archivo .xlsx con múltiples pestañas y/o CSVs que representan el inventario y configuración de la infraestructura simulada.

Ese dataset funciona como el “equivalente” de lo que en un proyecto real entregarías al equipo de migración desde tu entorno on-prem VMware.

👉 Ejemplo RVTools

RVTools es una de las herramientas más utilizadas para exportar inventario desde vCenter, incluyendo información de VMs, redes, CPU, memoria y almacenamiento. Este dataset suele ser el punto de partida para herramientas de migración y análisis.

📌 ¿Qué logramos con esta simulación?

Con el entorno simulado + RVTools export, habilitamos un flujo muy similar al de un piloto real:

• Tener un inventario estructurado (RVTools) con “señales” de infraestructura.
• Alimentar AWS Transform con ese dataset para que genere:
• Agrupaciones por aplicación o dependencias.
• Recomendaciones de red VMware→VPC.
• Wave planning.
• Conectar una cuenta destino y preparar la infraestructura target.
• Avanzar hacia ejecución integrando AWS MGN para el rehost a EC2 nativo.

En resumen: esta práctica no busca “migrar VMware en sí”, sino probar el proceso completo de planificación y migración usando los artefactos que se usan en la vida real, pero con un laboratorio repetible y seguro.

⭐ Habilitar AWS Transform y preparar el workspace

En la consola:

• Entrar a AWS Transform

• Habilitar el servicio AWS Transform en nuestra consola.

• Se selecciona la plataforma que utilizaremos para poder hacer login en el servicio. (AWS Transform web application para esta actividad).

• Debemos administrar los usuarios que podrán tener acceso a este servicio.

• Se asignan usuarios o grupos acceso (conexión con nuestro servicio de login en este caso "Identity Center").

👉 Debe mostrar una pantalla similar.

• Procedemos a iniciar sesión en el servicio de AWS Transform, copiando la URL indicada en en la imagen en nuestro en el navegador.

• COn los pasos anteriores, debemos tener ya habilitado el servicio de AWS Transform en nuestra consola.

⚡ Iniciamos nuestro proceso de trabajo en AWS Transform

• Creamos nuestro un Workspace

• Crea un Migration Job del tipo Migration

• Selecciona el tipo de Migración VMware Migration

AWS Transform prepara el entorno inicial (unos minutos) y te guía con tareas para el proceso.

• Seleccionamos el tipo de job que realizaremos

Para esta actividad, sera un End-to-End Migration

• Se inicia el Proceso, mostrando todos los pasos que se tomaran durante este proceso Job Plan.

Importación de Inventario (Fase 1 del Job Plan)

• Se procede a cargar el RVTools y se da submit y dejamos que la IA haga su trabajo

• Comienza el analisis del archivo RVTools.

Construcción Plan de Migacion (Fase 2 del Job Plan)

• Muestra información recopilada del RVTools y nos pide si queremos continuar con la construcción del Plan de migración.

El proceso va guiando e indicando algunas recomendaciones y opciones para la construcción del plan de migración.

• Despues de una serie de iteraciones se muestra una propuesta de plan de Migración.

En todo este proceso se combinan mejores prácticas con la información que entrega el cliente sobre sus cargas de trabajo. Esto nos permite interactuar con la herramienta y validar sus recomendaciones, ajustándolas cuando sea necesario, para construir un plan de trabajo realista y alineado con las necesidades del negocio y los requisitos técnicos.

• Revisado el plan de migración propuesto y hecha su aprobación, se procede a construir dicho plan.

• En la construcción del Plan se muestra, el sumario de Olas de migración (el cual se aprueba de estar de acuerdo).

Configuracion Cuenta destino de AWS (Fase 3 del Job Plan)

• Conexión cuenta target (cuenta destino en AWS)

Se configura cuenta

Procedemos a aprobar la conexión a esa cuenta target en el navegador, usando el link que entrega la herramienta. (Al finalizar debemos dar submit en AWS transform)

• Se muestra las primera 3 etapas listas.

Configuracion Cuenta destino de AWS (Fase 4 del Job Plan)

• Preparación del entorno de red de AWS.

Se puede cargar un nuevo archivo RVTols con la información o usar opción 1, el mismo archivo usado anteriormente (nuestra opción).

• SE selecciona el tipo de creación para la VPC. (para esta actividad será de tipo Isolated)

• Se muestra un resumen de las configuraciones indicadas a la herramienta para su análisis.

• AWS Transform te muestra 2 opciones para la realización del despliegue del networking en la cuenta target de AWS. (para esta actividad será de manera automática)

Se debe aprobar

Despues de aprobado el despliegue del networking, AWS Transform usa en Back, el servicio de CloudFormation, el cual se encargara de hacer el despliegue de lo definido en el paso anterior. }

Despues de realizada la construcción de la infraestructura de networking en la cuenta target, se nos muestra las 4 primeras actividades del Plan listas.

Ejecución del Plan de Migración (Fase 5 del Job Plan)

• Se aprueba el inicio del Plan de Migración.

• Se debe seleccionar las instancias EC2, que soportaran las cargas de trabajo a migrar.

• Se procede con las Olas de migración definidas en el Plan de Migración.

• Se debe habilitar el servicio MGN.

AWS Transform, usa el servicio AWS Application Migration Service (MGN) en Back, para realizar el proceso de migrar las cargas de trabajo, desde nuestro origen (on-premise o cuenta aws de simulación en nuestro caso), hasta la cuenta Target de AWS definida en el Plan de Migración.

• Se valida que todo los pasos previos estén OK, para proceder con la migración de la primera Ola.

• Muestra un resumen de lo que se realizara en el proceso de Migración de la Ola.

• El servicio AWS MGN comienza el proceso de replica a la cuenta target de AWS.

Nota: Previamente MGN instalo el agente de replicación en la maquina a migrar.

• Se inicia el proceso de sincronización.

• Fin del proceso de migración.

Una vez finalizada la fase de replicación y sincronización de las máquinas por cada ola, se procede con el cutover, que es el momento en que las cargas de trabajo pasan oficialmente del entorno de origen al entorno en AWS.

Durante este proceso, AWS Application Migration Service (MGN) ejecuta una serie de pasos automatizados para garantizar que la transición sea segura y consistente. Primero, el servicio valida que la replicación esté completamente sincronizada y que no existan cambios pendientes entre el servidor de origen y el entorno de destino. Luego se detiene temporalmente la máquina en el entorno de origen para asegurar la consistencia de los datos y evitar divergencias en el estado del sistema.

A continuación, MGN lanza una instancia EC2 basada en la última réplica sincronizada, utilizando la configuración previamente definida en las plantillas de lanzamiento (Launch Templates), donde se especifican parámetros como tipo de instancia, subred, grupos de seguridad y almacenamiento. Esta instancia representa la versión final del servidor ya ejecutándose en AWS.

Durante el cutover también se pueden ejecutar pruebas de validación, verificar conectividad, comportamiento de la aplicación y dependencias entre sistemas. En muchos casos, este paso forma parte de una ventana de mantenimiento controlada para minimizar el impacto en los usuarios o en los servicios productivos.

Una de las ventajas clave de AWS MGN es que permite realizar test cutovers antes del cutover final. Esto significa que se pueden lanzar instancias temporales en AWS para validar el funcionamiento de la aplicación sin interrumpir el sistema original, lo que reduce significativamente el riesgo durante la migración.

Finalmente, una vez confirmado que las instancias en AWS funcionan correctamente, se completa el proceso de cutover y las cargas de trabajo quedan operando en Amazon EC2, desde donde pueden continuar su proceso de optimización o modernización dentro del ecosistema de servicios de AWS.

Se debe repetir todos estos pasos de la Fase 5, para todas de las Olas definidas en el Plan de Migración.

🔧 Lecciones aprendidas

Durante el laboratorio aparecen algunos puntos interesantes:

• La calidad del inventario impacta directamente la calidad del plan.

• El wave planning automático acelera significativamente la planificación.

• La traducción de red VMware → VPC elimina gran parte del trabajo manual

-Los test cutovers de MGN reducen el riesgo antes de migraciones productivas.

💬 Conclusión

Este Post muestra por qué AWS Transform se siente como un “cambio de era”:

• Convierte un inventario tipo RVTools en un plan accionable.

• Acelera el diseño de red a VPC

• Baja la fricción para pasar a ejecución con MGN

Happy learnning on AWS!