Llevar una aplicación de un servidor on premise a la nube no es un proceso único. Existen siete estrategias de migración a la nube en AWS y cada una varía en complejidad, costo y nivel de transformación. Si eres arquitecto de soluciones o te preparas para el examen de Cloud Practitioner, entender cuándo aplicar cada una marca la diferencia entre una migración exitosa y un proyecto problemático.
¿Qué es rehost o lift and shift y cuándo conviene usarlo?
Es la estrategia más común y la más sencilla de ejecutar. Consiste en tomar una imagen de tu servidor on premise, por ejemplo uno con WordPress, y soltarla tal cual en la nube convirtiéndola en una instancia EC2 [00:32].
No cambias código ni configuración del sistema operativo. Solo arrastras la aplicación, la sueltas en la nube y queda funcionando igual. En migraciones grandes de miles de servidores, rehost suele ser el primer paso porque permite mover rápido y luego optimizar.
¿Qué es lift and shift en AWS? Es mover una aplicación existente a la nube sin modificar su código ni su configuración, generalmente como una instancia EC2 que replica el servidor original.
¿En qué se diferencia replatform de un rehost tradicional?
Replatform sube un escalón de complejidad. Imagina una aplicación dividida en servidor web y base de datos MySQL. En lugar de mover ambos como están, te llevas la base de datos a un servicio administrado como Amazon RDS, que es Platform as a Service [02:30].
Las ventajas son claras:
- Ya no administras el sistema operativo, lo hace el cloud provider.
- Aprovechas capacidades nativas de la nube desde el día uno.
- Reduces carga operativa para tu equipo.
Lo que cambia aquí es la plataforma sobre la que corre un componente, no la aplicación completa.
¿Cuándo elegir refactor frente a otras estrategias de migración?
Refactor es la estrategia más compleja de las siete. Significa rediseñar la aplicación para que aproveche al máximo la nube: contenedores orquestados con Kubernetes, almacenamiento en S3, base de datos en Aurora MySQL [04:10].
Tienes que entrar al código, repensar cómo se conectan los componentes y cómo monitoreas un clúster en lugar de un servidor. A cambio ganas escalabilidad real, soporte para picos de demanda altos e integración nativa con servicios de la nube.
¿Qué es repurchase y cómo funciona en el marketplace?
Repurchase es sustituir tu aplicación por una equivalente comprada en la nube. Vas al Marketplace de AWS, buscas una instancia con WordPress y MySQL preinstalados, la compras y solo migras el contenido del sitio [06:08].
No migras el servidor, recompras el servicio y mueves los datos. Es una opción rápida cuando existe un equivalente comercial listo para usar.
¿Por qué retain es una estrategia válida si no migras nada?
Retain significa dejar la aplicación donde está. Suena contraintuitivo, pero es una decisión consciente que aplica cuando:
- Una legislación de compliance impide mover la aplicación.
- El sistema operativo es muy viejo y no está soportado en la nube.
- Hablamos de un mainframe, un core bancario o un AS400 incompatible.
- La función no tiene sentido en la nube, como un servidor de impresión local.
En ejercicios reales con cientos de servidores, identificar qué no migrar es tan importante como decidir qué sí migrar [08:20].
¿Qué casos de uso justifican un relocate en VMware?
Relocate es una estrategia reciente y con un caso de uso muy específico: entornos VMware. Si tu empresa tiene 300 aplicaciones corriendo sobre un hipervisor VMware y todo tu equipo domina esa tecnología, no tiene sentido obligarlos a aprender algo nuevo.
Con relocate te llevas el hipervisor y las máquinas virtuales tal como están a la nube. Piénsalo como un rehost a nivel de hipervisor [09:45]. Aprovechas las ventajas de AWS sin arriesgar el conocimiento acumulado del equipo.
¿Cuál es la diferencia entre rehost y relocate? Rehost mueve un servidor individual como instancia EC2. Relocate mueve todo el hipervisor VMware con sus máquinas virtuales, manteniendo la capa de virtualización original.
¿Cuándo aplicar retire durante una migración?
Retire identifica los servicios que se eliminan en el proceso. De 50 aplicaciones inventariadas, quizá solo migras 40 y las otras 10 mueren en el camino [10:50].
Ejemplos típicos:
- Servidores de monitoreo como Nagios o Zabbix que reemplazas por herramientas nativas del cloud provider.
- Hipervisores que ya no necesitas porque migras de forma nativa a EC2.
- Aplicaciones duplicadas o sin uso real detectadas en el inventario.
Retire saca esos servicios del scope de la migración y limpia el portafolio.
¿Cómo elegir la estrategia correcta en un escenario real?
Piensa en este caso típico de examen Cloud Practitioner: una aplicación web on premise se cae varias veces al mes por demanda. Se acerca una campaña de marketing grande, el CTO te da presupuesto y acceso al equipo de desarrollo, y necesitas que escale bien en la nube [12:30].
Las opciones son:
- Rehost más autoescalamiento.
- Refactor llevando la aplicación a contenedores con Fargate.
- Repurchase con autoescalamiento.
- Retain.
La respuesta correcta es refactor. Tienes presupuesto para invertir en desarrollo, equipo capacitado para hacer cambios profundos y la necesidad de escalabilidad alta justifica el rediseño completo. Con EKS sobre Fargate, la aplicación soporta picos sin caerse.
¿Qué estrategia aplicarías tú en tu próxima migración? Cuéntame en los comentarios cuál es el escenario que estás enfrentando.
