Estrategia de migración de cargas de trabajo VMware - Un enfoque por fases que combina MGN y EVS según el caso
Este artículo explica cómo elegir entre MGN (Application Migration Service) y EVS al migrar cargas de trabajo VMware a AWS, cómo elaborar un plan de migración por fases y la optimización después de la migración.
Los 3 enfoques de la migración de VMware
Los métodos para migrar cargas de trabajo VMware a AWS se clasifican a grandes rasgos en tres. El primero, lift & shift, es un método que traslada el entorno VMware tal cual a AWS con Amazon EVS. No es necesario modificar las aplicaciones, pero las licencias de VMware siguen siendo necesarias. El segundo, el replatforming, es un método que convierte las VM de VMware en instancias EC2 con AWS MGN (Application Migration Service). Le libera de las licencias de VMware, pero es necesario verificar la compatibilidad del sistema operativo y del middleware. El tercero, la refactorización, es un método que contenedoriza las aplicaciones y las ejecuta en ECS o EKS. Es la forma más cloud native, pero el esfuerzo de modificación de las aplicaciones resulta grande.
Evaluación de la migración y elaboración del plan
Antes de la migración, si ya utiliza AWS Migration Hub (que dejó de aceptar nuevos clientes a partir del 7 de noviembre de 2025), puede recopilar el inventario del entorno existente y mapear las dependencias entre cargas de trabajo. Con Migration Evaluator (antes TSO Logic), puede calcular la configuración óptima y una estimación de costes en AWS a partir de los datos de uso de su entorno on-premises actual. A partir de los resultados de la evaluación, usted determina si cada carga de trabajo se migrará con EVS, con MGN o mediante refactorización. Como criterio de decisión, usted elige EVS para las cargas de trabajo con una alta dependencia de funciones específicas de VMware (vMotion, DRS, HA), MGN para los servidores Linux/Windows estándar y la refactorización para las aplicaciones en las que se prevé la adopción de microservicios.
Migración a EC2 con MGN en la práctica
AWS MGN instala un agente en el servidor de origen y crea una réplica en AWS mediante replicación continua a nivel de bloque. Como el servidor de origen sigue funcionando durante la replicación, no hay impacto en las operaciones del negocio. Usted verifica el funcionamiento de la réplica con un lanzamiento de prueba y, si no hay problemas, ejecuta el cutover para cambiar a producción. El tiempo de inactividad durante el cutover es solo el tiempo de sincronización de las últimas diferencias (normalmente de unos minutos a unas decenas de minutos). En MGN, el agente puede coexistir con VMware Tools, por lo que puede instalarlo tal cual en los servidores de un entorno vSphere. Después de la migración, los servidores funcionan como instancias EC2, por lo que puede aprovechar funciones nativas de AWS como la integración con Auto Scaling y ALB.
Consideraciones sobre los costes de migración
El uso de MGN es gratuito, y solo se generan los costes del área de staging para la replicación (EC2 + EBS). En EVS, la tarifa de los hosts dedicados (i4i.metal) es el principal factor de coste, con aproximadamente 15,000 USD o más al mes en la configuración mínima de 3 hosts (a fecha de agosto de 2026). Como la elección del método de migración afecta mucho al coste, usted evalúa con cuidado el equilibrio entre la migración a EC2 con MGN (coste bajo, requiere cambios en la aplicación) y el traslado del entorno VMware con EVS (coste alto, sin cambios). Usted analiza los costes del entorno actual con Migration Evaluator y estima el TCO después de la migración antes de decidir el método.
Organización de las estrategias de migración
Existen varios enfoques para la migración a la nube. Con el método de trasladar las máquinas virtuales casi tal cual, puede migrar en poco tiempo con pocos cambios, y elegirlo es adecuado cuando usted quiere, ante todo, ponerlas en marcha de forma fiable. El método de sustituir parte del sistema operativo y del middleware y optimizar el sistema para la nube logra un equilibrio entre la reducción de la carga operativa y la velocidad de migración. El método de reconstruir las aplicaciones para hacerlas cloud native requiere esfuerzo, pero con él puede obtener el mayor efecto. En lugar de migrarlo todo con el mismo método, una estrategia realista es elegir el método según la importancia de cada aplicación y el margen de modificación, y avanzar por fases.
Funcionamiento y características de MGN
Application Migration Service (MGN) es un medio representativo para migrar servidores en funcionamiento a AWS casi tal cual. Al seguir replicando de forma continua los datos de los servidores de origen, puede preparar la migración sin detener la producción. Antes del cambio, puede lanzar instancias de prueba a partir de los datos replicados y verificar de antemano si funcionan correctamente en el destino de la migración. En el cambio a producción, usted realiza el cambio a partir de un estado sincronizado hasta justo antes del cambio, por lo que puede reducir al mínimo el tiempo de inactividad. Poder migrar de forma segura y con un tiempo de parada corto sin cambiar mucho la configuración existente es una gran ventaja de usar MGN.
Optimización y modernización después de la migración
Después de migrar los servidores tal cual, usted pasa a la optimización que aprovecha las ventajas de la nube. Usted mide el uso real, ajusta las instancias sobredimensionadas a un tamaño adecuado y reduce los costes. Además, si avanza por fases en la modernización, como trasladar las bases de datos a servicios gestionados o sustituir el procesamiento por contenedores o serverless, puede reducir la carga operativa y aumentar la escalabilidad. Al adoptar un enfoque en dos etapas, primero migrar de forma fiable y poner en marcha los sistemas y después mejorar de forma repetida, puede maximizar a largo plazo los beneficios de la nube mientras mantiene bajo control el riesgo de la migración. Usted considera la migración como el punto de partida de la optimización.
Cómo llevar adelante un proyecto de migración
Para que una migración a gran escala tenga éxito, no solo es importante la tecnología, sino también el diseño de la forma de avanzar. Si prepara el entorno de AWS de destino con la base de seguridad y permisos ya establecida, puede recibir cada carga de trabajo de forma segura. Usted agrupa los objetivos de la migración por dependencias, les asigna prioridades y avanza por fases. Usted aplica a las migraciones posteriores lo aprendido en la primera oleada para aumentar la eficiencia. En paralelo, también prepara al equipo para que se familiarice con la operación en la nube. En lugar de intentar migrarlo todo de una vez, avanzar de forma constante mientras repite el ciclo de planificación / ejecución / verificación / mejora lleva el proyecto de migración al éxito.
Resumen - Estrategia recomendada de migración por fases
Para migrar cargas de trabajo VMware a AWS, es eficaz una estrategia por fases que combine EVS y MGN según las características de cada carga de trabajo, en lugar de un único enfoque. Primero, usted migra los entornos de desarrollo / pruebas a EC2 con MGN para acumular conocimientos de operación en la nube, y los entornos de producción los traslada con lift & shift a EVS y después los convierte a EC2 de forma sucesiva. Después de la migración, usted optimiza el tamaño de las instancias con Compute Optimizer y reduce los costes con Savings Plans. Con un abandono gradual de las licencias de VMware, puede lograr una reducción de los costes operativos a largo plazo.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
- AWS MGN (página oficial)
- Amazon EVS (página oficial)
- AWS Migration Hub (página oficial)
- Documentación de AWS (oficial)
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.