Migración cloud paso a paso: un framework para CTOs

Por qué la mayoría de migraciones cloud se pasan de presupuesto

El 38% de las migraciones cloud superan el presupuesto inicial en más de un 20%, según Flexera 2024. La causa no es técnica. Es que las empresas empiezan a migrar sin un framework de decisión claro, impulsadas por la presión del vendor o por la idea genérica de que “hay que ir a cloud”.

Una migración cloud bien ejecutada reduce costes operativos, mejora la escalabilidad y acelera el time-to-market. Una migración mal planificada genera costes inesperados, degradación de rendimiento y equipos frustrados. La diferencia no está en la tecnología elegida sino en la calidad de la preparación.

Fase 1: assessment sin autoengaño

Antes de mover nada, necesitas un inventario brutal de lo que tienes. No lo que crees que tienes; lo que realmente tienes.

Inventario de aplicaciones. Cada aplicación con sus dependencias, volúmenes de datos, patrones de tráfico, requisitos de latencia, y restricciones regulatorias. Hemos visto organizaciones que descubrieron durante la migración que una aplicación crítica dependía de una librería que solo funcionaba en Windows Server 2012. Ese tipo de sorpresas se evitan en el assessment.

Análisis de dependencias. Las aplicaciones no viven aisladas. Un ERP que habla con un CRM, que habla con un sistema de facturación, que habla con un banco. El grafo de dependencias determina qué puede moverse independientemente y qué tiene que moverse junto.

Línea base de costes actuales. El coste real de tu infraestructura on-premise incluye hardware, licencias, electricidad, refrigeración, espacio físico, y el tiempo del equipo que la mantiene. Muchas empresas subestiman este coste porque está repartido en diferentes centros de coste. Sin una línea base fiable, no puedes comparar con cloud.

Requisitos regulatorios. Residencia de datos, compliance sectorial (PCI-DSS para pagos, HIPAA para salud, regulación financiera), y políticas internas de seguridad. Estos requisitos pueden eliminar opciones de cloud o de región antes de empezar.

Fase 2: las 6Rs de la decisión

No todas las aplicaciones merecen el mismo tratamiento. Las 6Rs de AWS (originalmente de Gartner) proporcionan un marco de decisión:

Rehost (lift-and-shift). Mover la aplicación tal cual a cloud, normalmente a VMs. Es la opción más rápida y menos arriesgada. No captura los beneficios nativos de cloud, pero te saca del datacenter. Tiene sentido para aplicaciones estables que no vas a modificar pronto.

Replatform (lift-and-reshape). Pequeñas optimizaciones durante la migración: mover la base de datos a un servicio gestionado (RDS en lugar de MySQL en una VM), usar un balanceador de carga nativo, externalizar la gestión de sesiones a ElastiCache. Effort moderado, beneficio inmediato en operaciones.

Refactor. Rediseñar la aplicación para aprovechar servicios cloud nativos: contenedores, serverless, colas gestionadas, bases de datos especializadas. Es la opción con mayor beneficio a largo plazo y mayor coste a corto. Solo tiene sentido para aplicaciones con desarrollo activo y una vida útil larga por delante.

Repurchase. Sustituir la aplicación por un SaaS. Tu CRM on-premise por Salesforce. Tu correo por Google Workspace. No es una migración técnica, es una decisión de negocio.

Retire. Apagar la aplicación. En toda organización hay aplicaciones que nadie usa pero nadie se atreve a apagar. El assessment es el momento de identificarlas. En nuestra experiencia, entre el 10% y el 20% de las aplicaciones inventariadas son candidatas a retirar.

Retain. Dejarla donde está. Algunas aplicaciones tienen restricciones que hacen la migración inviable o antieconómica a corto plazo. Mainframes, aplicaciones con dependencias de hardware específico, o sistemas con contratos de licencia que penalizan la migración.

La distribución típica que vemos en empresas mid-market españolas: 40% rehost, 25% replatform, 15% refactor, 10% repurchase, 5% retire, 5% retain. Pero cada organización es diferente, y forzar una distribución “ideal” es un error.

Fase 3: modelado de costes real

El modelado de costes de cloud tiene trampas que los calculadores de los vendors no hacen evidentes.

Coste de computación. Los precios on-demand son la referencia, pero nadie debería pagar on-demand para cargas estables. Reserved Instances (1 o 3 años) o Savings Plans reducen el coste de cómputo un 30-60%. La clave es dimensionar correctamente: sobredimensionar en cloud es tan fácil (y caro) como en on-premise. Un framework FinOps ayuda a controlar estos costes desde el primer día.

Coste de datos. El egress de datos (datos que salen de cloud) tiene coste. Y puede ser significativo. Una aplicación que sirve 10TB de datos al mes a usuarios externos va a tener una factura de egress que sorprende. Este es el coste que más se infravalora en las estimaciones iniciales.

Coste de almacenamiento. Parece barato por GB, y lo es. Pero los datos crecen, y las políticas de lifecycle que borran datos antiguos rara vez se implementan. Hemos visto organizaciones cuyo coste de S3 creció un 15% mensual durante dos años porque nadie configuró lifecycle policies.

Coste oculto. Soporte premium, servicios de red (NAT gateways, Transit Gateways, IPs elásticas), logging y monitoring a escala, y transferencia entre zonas de disponibilidad. Estos costes suman un 15-25% sobre la estimación base si no se modelan explícitamente.

Un modelo de costes realista proyecta a 3 años, incluye un escenario optimista, uno realista y uno pesimista, y se revisa trimestralmente contra el gasto real. Cualquier cosa menos rigurosa es una invitación a sorpresas.

Fase 4: ejecución por olas

La migración se ejecuta en olas, no en big bang. Cada ola es un grupo de aplicaciones que se mueven juntas, seleccionadas por:

• Dependencias mutuas (tienen que moverse juntas)
• Criticidad de negocio (empezar por las menos críticas)
• Complejidad técnica (empezar por las más simples)
• Impacto en equipo (no saturar un solo equipo)

Ola 0: prueba de concepto. Una o dos aplicaciones no críticas para validar la infraestructura base, los pipelines de despliegue, el networking, la seguridad y los procesos operativos. Esta ola dura 4-6 semanas y su objetivo principal es aprender, no migrar.

Olas 1-N: migración incremental. Cada ola migra 3-8 aplicaciones en 2-4 semanas. Cada ola tiene su propio plan de rollback. El rollback no es “volver a encender el servidor viejo” (aunque a veces si lo es); es un procedimiento documentado y testado que permite revertir si algo sale mal.

Post-migración. Después de cada ola: validación funcional, tests de rendimiento, revisión de costes contra la estimación, y retrospectiva del equipo. Los aprendizajes de cada ola alimentan la planificación de la siguiente.

Las trampas que no cuentan

El “cloud premium” de los vendors. El equipo de ventas de AWS, Azure o GCP va a proponer servicios gestionados premium para todo. Algunos merecen la pena (bases de datos gestionadas, casi siempre). Otros son innecesariamente caros para lo que ofrecen. Evalúa cada servicio gestionado contra la alternativa open source o self-managed. A veces la diferencia de precio es de 5x.

Vendor lock-in progresivo. Cada servicio propietario que usas es un ancla. Para entender las implicaciones reales del lock-in, consulta nuestro análisis sobre estrategia multi-cloud. Lambda te ata a AWS. Cloud Functions te ata a GCP. Azure Functions te ata a Azure. Esto no significa que debas evitarlos (a veces la productividad lo justifica), pero debes ser consciente del coste de salida.

La migración del equipo. Tu equipo de operaciones sabe gestionar servidores físicos y VMware. Cloud requiere competencias diferentes: IaC, networking virtual, IAM, servicios gestionados. Sin un plan de formación serio (no webinars de 45 minutos, sino formación práctica de semanas), la migración técnica se completará pero la operación será frágil.

Networking. La conectividad entre tu entorno on-premise residual y cloud (VPN, Direct Connect/ExpressRoute) es el componente más subestimado técnicamente. Problemas de latencia, DNS, y routing entre entornos causan más incidentes post-migración que cualquier otro factor.

Una migración cloud es un proyecto de transformación operativa, no un proyecto de infraestructura. La tecnología es la parte fácil. Las personas, los procesos y las decisiones de arquitectura son lo que determina si sale bien o se convierte en una fuente de problemas durante años.