¿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 mover aplicaciones, datos o cargas de trabajo de un entorno informático a otro — más comúnmente desde centros de datos on-premise a un proveedor de nube pública (AWS, Azure, GCP), pero cada vez más cloud-a-cloud ("migración de segunda generación") y cloud-a-on-prem ("repatriación") son categorías reales también. La migración a la nube es la categoría más grande de infraestructura en el gasto de TI empresarial — Gartner pronostica un gasto global en nube pública de 700 mil millones $+ para 2026 — y sigue siendo uno de los esfuerzos de ingeniería más arriesgados y caros que la mayoría de las organizaciones emprenden.

La decisión de migrar raramente está impulsada puramente por la tecnología. Coste, agilidad, posicionamiento regulatorio, retención de talento, consolidación de proveedores y preocupaciones de salida-de-centros-de-datos-envejecidos todos cuentan. La buena noticia: el playbook para la migración a la nube ahora es maduro. La mala: la mayoría de las organizaciones todavía subestiman las fases de pruebas y optimización post-migración, y terminan con facturas de nube 2-3× más altas que las proyectadas durante los primeros 12-18 meses.

Las 6 Rs de la migración a la nube (framework AWS)

La taxonomía estándar de AWS, usada en toda la industria:

1. Rehost ("lift and shift") — mover cargas de trabajo tal cual a VMs en nube. Ejecución más rápida y barata. Captura poco valor cloud más allá del intercambio CapEx → OpEx.
2. Replatform ("lift, tinker, and shift") — optimizaciones menores durante la migración (p.ej., PostgreSQL auto-gestionado → RDS PostgreSQL). Camino medio común.
3. Repurchase (intercambio SaaS) — reemplazar apps auto-hospedadas con SaaS (Exchange → Microsoft 365, CRM on-prem → Salesforce).
4. Refactor / re-architect — reescribir para cloud-native (monolito → microservicios, VMs → contenedores/serverless). Mayor valor cloud; mayor coste + riesgo.
5. Retire — apagar la carga de trabajo completamente. ~10% de las apps inventariadas en la mayoría de las evaluaciones no se usan.
6. Retain — dejar on-prem (cumplimiento, cargas sensibles a latencia, hardware comprado recientemente).

Las fases de una migración real

1. Descubrimiento + evaluación

Inventariar todo — apps, dependencias, flujos de datos, requisitos de red, términos de licencia. Herramientas: AWS Application Discovery Service, Azure Migrate, GCP Migrate Center, terceros (CloudPhysics, Tanzu CloudHealth). Salida: un Plan de Olas que agrupa apps por orden de migración.

2. Ola piloto (5-10 apps)

Migrar apps no críticas primero para construir la memoria muscular del equipo y validar la configuración de zona de aterrizaje (VPC, IAM, networking, monitoring). Las lecciones aquí se propagan a olas posteriores.

3. Olas de migración de producción

Secuenciadas por criticidad de app, dependencias y tolerancia al downtime. Cada ola tiene su propio plan de cutover: método de sync de datos, estrategia DNS, plan de rollback, plan de comm, monitoring.

4. Optimización (post-migración)

La fase que la mayoría de las organizaciones se saltan y luego lamentan. Right-size instancias, reservar capacidad, eliminar recursos idle, refactor para servicios cloud-native, optimizar costes de transferencia de datos. La mayoría del sobregasto en cloud sucede aquí — las cargas de trabajo siguen ejecutándose con el dimensionamiento de lift-and-shift porque nadie posee la optimización post-migración.

Trampas comunes de migración a la nube

• Lift-and-shift de todo. Barato de ejecutar, caro de operar. Sin optimización, los costes cloud cuestan ~2× el TCO on-prem por cómputo equivalente.
• Ignorar el egress de datos. Las transferencias cross-AZ + cross-region + cloud-a-internet suman rápido. Arquitectiona la ubicación de datos para minimizar el egress.
• No probar bajo carga. El networking, storage e IAM en cloud se comportan diferente al on-prem. Las apps que funcionaban bien on-prem a menudo fallan bajo patrones de carga de producción en cloud.
• Subestimar la migración de identidad. AD → Azure AD, LDAP on-prem → Cognito/Okta es una de las dependencias más duras en cualquier migración.
• Saltarse las barandas de coste. Tags, presupuestos, alertas, políticas IAM que previenen instancias EC2 de 10k $. Faltarlas = facturas sorpresa de 30k $ en el mes 1.
• Tratar la migración como one-and-done. El cloud evoluciona continuamente — tu arquitectura necesita atención continua o se osifica en el diseño del primer año.
• No probar el plan de rollback. Si la migración va mal, hacer rollback al on-prem a menudo es imposible porque el entorno on-prem fue desmantelado. Prueba los rollbacks durante la ola piloto.

FAQ: Migración a la Nube

¿Cuánto tarda una migración típica?

Altamente variable. Una migración SMB de 50 apps: 6-12 meses. Una migración empresarial de 500 apps: 2-5 años. Despliegues cloud-native greenfield sin migración: semanas a meses.

¿Qué hay sobre multi-cloud?

Común como estrategia ("evitar el lock-in") pero operativamente complejo. La mayoría de los equipos terminan con una nube primaria + uso de nicho de otras. La verdadera portabilidad entre nubes es cara de mantener.

¿Debería migrar todo?

No. Algunas cargas (mainframe, HFT sensible a latencia, hardware on-prem comprado recientemente, datos con requisitos regulatorios de residencia de datos) no deberían migrar. El framework 6Rs incluye "Retain" por una razón.

¿Cómo presupuesto los costes cloud con precisión?

Usa los calculadores TCO del proveedor cloud (AWS Pricing Calculator, Azure TCO Calculator) para dimensionamiento inicial. Luego añade un buffer del 30-50% para el primer año — la mayoría de los proyectos encuentran costes inesperados de egress, soporte o formación.

¿Qué es la "repatriación cloud"?

Mover cargas de trabajo de la nube de vuelta a on-prem (o co-location). Categoría real en 2026 — empresas como 37signals/Basecamp se repatriaron públicamente. Impulsores comunes: coste, cumplimiento, patrones de carga predecibles donde la prima de elasticidad del cloud no vale la pena.

¿Debería hacer lift-and-shift o refactorizar?

Depende de la app. ¿App estable, crítica para el negocio con carga predecible? Lift-and-shift primero, optimizar después. ¿Producto nuevo con tráfico creciente + necesidad de escala cloud-native? Refactor o reconstruir greenfield.

Cómo se relaciona LoadFocus con la validación de migración a la nube

El paso más-saltado en las migraciones a la nube es la validación de rendimiento + capacidad pre-cutover. Las pruebas de carga LoadFocus validan que las apps migradas manejen la carga concurrente esperada antes de cambiar DNS — sacando a la luz cuellos de botella específicos del cloud (latencia cross-AZ, límites de tasa de llamadas IAM, storage throttled) en la fase de prueba, no en el cutover. La monitorización de API rastrea la latencia por endpoint post-migración para que atrapes regresiones vs. la línea base on-prem.