Migracion cloud paso a paso: un framework para CTOs

Por que la mayoria de migraciones cloud se pasan de presupuesto

El 38% de las migraciones cloud superan el presupuesto inicial en mas de un 20%, segun Flexera 2024. La causa no es tecnica. Es que las empresas empiezan a migrar sin un framework de decision claro, impulsadas por la presion del vendor o por la idea generica de que “hay que ir a cloud”.

Una migracion cloud bien ejecutada reduce costes operativos, mejora la escalabilidad y acelera el time-to-market. Una migracion mal planificada genera costes inesperados, degradacion de rendimiento y equipos frustrados. La diferencia no esta en la tecnologia elegida sino en la calidad de la preparacion.

Fase 1: assessment sin autoengano

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 aplicacion con sus dependencias, volumenes de datos, patrones de trafico, requisitos de latencia, y restricciones regulatorias. Hemos visto organizaciones que descubrieron durante la migracion que una aplicacion critica dependia de una libreria que solo funcionaba en Windows Server 2012. Ese tipo de sorpresas se evitan en el assessment.

Analisis de dependencias. Las aplicaciones no viven aisladas. Un ERP que habla con un CRM, que habla con un sistema de facturacion, que habla con un banco. El grafo de dependencias determina que puede moverse independientemente y que tiene que moverse junto.

Linea base de costes actuales. El coste real de tu infraestructura on-premise incluye hardware, licencias, electricidad, refrigeracion, espacio fisico, y el tiempo del equipo que la mantiene. Muchas empresas subestiman este coste porque esta repartido en diferentes centros de coste. Sin una linea base fiable, no puedes comparar con cloud.

Requisitos regulatorios. Residencia de datos, compliance sectorial (PCI-DSS para pagos, HIPAA para salud, regulacion financiera), y politicas internas de seguridad. Estos requisitos pueden eliminar opciones de cloud o de region antes de empezar.

Fase 2: las 6Rs de la decision

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

Rehost (lift-and-shift). Mover la aplicacion tal cual a cloud, normalmente a VMs. Es la opcion mas rapida 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). Pequenas optimizaciones durante la migracion: 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 gestion de sesiones a ElastiCache. Effort moderado, beneficio inmediato en operaciones.

Refactor. Redisenar la aplicacion para aprovechar servicios cloud nativos: contenedores, serverless, colas gestionadas, bases de datos especializadas. Es la opcion con mayor beneficio a largo plazo y mayor coste a corto. Solo tiene sentido para aplicaciones con desarrollo activo y una vida util larga por delante.

Repurchase. Sustituir la aplicacion por un SaaS. Tu CRM on-premise por Salesforce. Tu correo por Google Workspace. No es una migracion tecnica, es una decision de negocio.

Retire. Apagar la aplicacion. En toda organizacion 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 esta. Algunas aplicaciones tienen restricciones que hacen la migracion inviable o antieconómica a corto plazo. Mainframes, aplicaciones con dependencias de hardware especifico, o sistemas con contratos de licencia que penalizan la migracion.

La distribucion tipica que vemos en empresas mid-market espanolas: 40% rehost, 25% replatform, 15% refactor, 10% repurchase, 5% retire, 5% retain. Pero cada organizacion es diferente, y forzar una distribucion “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 computacion. Los precios on-demand son la referencia, pero nadie deberia pagar on-demand para cargas estables. Reserved Instances (1 o 3 anos) o Savings Plans reducen el coste de computo un 30-60%. La clave es dimensionar correctamente: sobredimensionar en cloud es tan facil (y caro) como en on-premise. Un framework FinOps ayuda a controlar estos costes desde el primer dia.

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

Coste de almacenamiento. Parece barato por GB, y lo es. Pero los datos crecen, y las politicas de lifecycle que borran datos antiguos rara vez se implementan. Hemos visto organizaciones cuyo coste de S3 crecio un 15% mensual durante dos anos porque nadie configuro lifecycle policies.

Coste oculto. Soporte premium, servicios de red (NAT gateways, Transit Gateways, IPs elasticas), logging y monitoring a escala, y transferencia entre zonas de disponibilidad. Estos costes suman un 15-25% sobre la estimacion base si no se modelan explicitamente.

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

Fase 4: ejecucion por olas

La migracion 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 criticas)
• Complejidad tecnica (empezar por las mas simples)
• Impacto en equipo (no saturar un solo equipo)

Ola 0: prueba de concepto. Una o dos aplicaciones no criticas 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: migracion 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-migracion. Despues de cada ola: validacion funcional, tests de rendimiento, revision de costes contra la estimacion, y retrospectiva del equipo. Los aprendizajes de cada ola alimentan la planificacion 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. Evalua 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 analisis 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 migracion del equipo. Tu equipo de operaciones sabe gestionar servidores fisicos y VMware. Cloud requiere competencias diferentes: IaC, networking virtual, IAM, servicios gestionados. Sin un plan de formacion serio (no webinars de 45 minutos, sino formacion practica de semanas), la migracion tecnica se completara pero la operacion sera fragil.

Networking. La conectividad entre tu entorno on-premise residual y cloud (VPN, Direct Connect/ExpressRoute) es el componente mas subestimado tecnicamente. Problemas de latencia, DNS, y routing entre entornos causan mas incidentes post-migracion que cualquier otro factor.

Una migracion cloud es un proyecto de transformacion operativa, no un proyecto de infraestructura. La tecnologia es la parte facil. 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 anos.