¿Qué es la migración a la nube?

¿Qué es la migración a la nube?

La migración a la nube es el proceso de trasladar aplicaciones, datos y cargas de trabajo de un entorno a otro, casi siempre de servidores propios a una nube pública como AWS, Azure o Google Cloud. También incluye los traslados entre nubes y de vuelta a infraestructura propia (repatriación). Una migración puede ser el simple traslado de un servidor o un rediseño de la aplicación para usar servicios gestionados en la nube.

Las 7 R de la migración a la nube

AWS describe siete estrategias de migración, conocidas como las 7 R. Se elige una por aplicación, no una para todo el parque.

• Rehost (lift and shift). Mover la aplicación tal cual, sin cambios.
• Replatform (lift, tinker and shift). Moverla y hacer algunas optimizaciones, como pasar de una base de datos autogestionada a una gestionada.
• Refactor o rediseño. Rediseñarla para aprovechar funciones nativas de la nube. La más compleja y cara de las siete.
• Relocate. Mover servidores o instancias a la versión cloud de la misma plataforma, o a otra cuenta, VPC o región, sin cambiar la arquitectura.
• Repurchase (drop and shop). Sustituir la aplicación por un SaaS o un producto más reciente.
• Retire. Apagar las aplicaciones que nadie necesita. AWS propone como candidatas, por ejemplo, las apps sin conexiones entrantes en 90 días.
• Retain. Dejarla donde está, por ejemplo por residencia de datos, hardware especializado, un mainframe o una compra reciente de hardware.

Para migraciones grandes, AWS recomienda empezar con rehost, relocate o replatform y modernizar después, porque refactorizar durante el traslado es lo más difícil de gestionar.

Fases de una migración

1. Evaluar y planificar

Inventaria aplicaciones, dependencias, flujos de datos, necesidades de red y licencias. Agrupa las aplicaciones en oleadas y elige una estrategia para cada una. Anota el rendimiento actual, porque será tu referencia después.

2. Construir la landing zone

Configura cuentas, red, identidad, registros y control de costes antes de mover nada. Definirla como código con infraestructura como código la mantiene repetible. Consulta la gobernanza cloud para ver las reglas que conviene fijar pronto.

3. Oleada piloto

Mueve primero unas pocas aplicaciones de bajo riesgo para probar la landing zone, los pasos del cambio y el plan de marcha atrás.

4. Oleadas de migración

Cada oleada tiene un método de sincronización de datos, un plan de cambio de DNS, un plan de marcha atrás y monitorización. Prueba antes del cambio, no después.

5. Optimizar y operar

Ajusta el tamaño de las instancias, elimina recursos ociosos, revisa los costes de transferencia de datos y moderniza lo que migraste tal cual. Sigue el resultado con la monitorización cloud.

Ejemplo

Una empresa tiene una tienda web en dos servidores propios con una base de datos MySQL autogestionada. Elige replatform: la app pasa a máquinas virtuales en la nube y la base de datos a un servicio MySQL gestionado. Antes del cambio ejecuta una prueba de carga con el pico esperado contra el nuevo entorno y compara tiempos de respuesta y tasa de errores con las cifras registradas en los servidores antiguos. Cambia el DNS solo cuando el nuevo entorno iguala o mejora esas cifras, y conserva los servidores antiguos durante un plazo definido como vía de vuelta atrás.

Errores habituales en la migración a la nube

• Hacer rehost de todo y parar. El traslado es rápido, pero sin ajustar tamaños ni limpiar se paga por máquinas sobredimensionadas.
• Saltarse la referencia. Sin mediciones del entorno antiguo no sabrás si la versión en la nube es más lenta.
• No probar bajo carga. Las rutas de red, el rendimiento del almacenamiento, los límites de los servicios gestionados y las llamadas de identidad se comportan distinto que en el antiguo centro de datos.
• Ignorar los costes de transferencia. El tráfico entre zonas, regiones y hacia internet se factura, así que la ubicación de los datos importa.
• Dejar la identidad para el final. Las dependencias de directorio y de inicio de sesión único suelen bloquear el cambio.
• Sin límites de coste. Presupuestos, etiquetas y alertas deben existir antes de que llegue la primera carga.
• Apagar demasiado pronto el entorno antiguo. Consérvalo hasta que el plan de marcha atrás no haya hecho falta durante un plazo acordado.
• Forzar un refactor dentro del traslado. Dividir un monolito en microservicios durante la migración añade riesgo. Migra primero, moderniza después.

Validar una migración con pruebas y monitorización

El paso que más se omite es demostrar que la aplicación migrada rinde. Ejecuta una prueba de carga contra el nuevo entorno con el tráfico pico esperado y compárala con tu referencia. La plataforma de load testing de LoadFocus ejecuta pruebas JMeter y k6 desde 25 regiones cloud, de modo que puedes generar tráfico desde donde están tus usuarios. Tras el cambio, la monitorización de API comprueba de forma programada códigos de estado, cuerpos de respuesta y tiempo de respuesta, y te avisa cuando fallan. Para la parte de pruebas de la decisión, lee cloud vs on-premise load testing (en inglés).

Preguntas frecuentes: migración a la nube

¿Cuánto dura una migración a la nube?

Depende del número de aplicaciones, de sus dependencias y de la estrategia elegida. Un rehost de unos pocos servidores sencillos puede llevar semanas, mientras que un portfolio grande se planifica en oleadas durante meses o años. Considera cualquier cifra suelta una estimación hasta terminar la evaluación.

¿Qué diferencia hay entre rehost y replatform?

El rehost mueve la aplicación sin cambios. El replatform la mueve y hace algunas optimizaciones, como pasar a una base de datos gestionada, sin rediseñar la aplicación.

¿Debe migrar toda aplicación a la nube?

No. Algunas se retiran y otras se mantienen por cumplimiento normativo, hardware especializado o una inversión reciente. Las 7 R incluyen ambas opciones por eso.

¿Qué es la repatriación de la nube?

Volver a llevar cargas de trabajo de la nube a infraestructura propia o a un centro de colocation. Los equipos lo hacen por coste, cumplimiento o cargas predecibles que no sacan partido de la capacidad elástica.

¿Cómo pruebo una migración antes del cambio?

Anota tiempos de respuesta y tasas de error del entorno antiguo como referencia, ejecuta una prueba de carga con el pico esperado contra el nuevo, compara los resultados y ensaya la marcha atrás. Cambia el tráfico solo cuando las cifras coincidan.