Cuando urge dejar el datacenter, la tentación es obvia: "levantemos los servidores tal cual y movámoslos a la nube". Se llama lift-and-shift, es rápido, y a veces es exactamente lo correcto. El problema es quedarse ahí para siempre —porque entonces empiezas a pagar precios de nube por hábitos de servidor propio, y la nube que prometía ahorro se vuelve más cara que lo que dejaste—.
Las estrategias de migración, en contexto
Se suele hablar de varias "R" de migración: rehost (lift-and-shift, mover tal cual), replatform (adaptar para aprovechar la nube sin reescribir), refactor (rediseñar la aplicación para la nube), repurchase (cambiar a un SaaS), retain (dejarla donde está) y retire (apagar lo que ya no sirve). No hay que migrar todo igual; cada carga entra en una categoría. La disyuntiva práctica más común, y la más malentendida, es entre las dos primeras.
Lift-and-shift: rápido, pero sin aprovechar nada
Mover una carga tal cual —el mismo servidor, ahora en una VM de la nube— tiene bajo esfuerzo inicial y saca tu operación del hierro viejo pronto. Pero no aprovecha lo que hace valiosa a la nube: la VM sigue encendida 24/7 pagándose por hora como si fuera física, sin escalado (no crece ni se encoge con la demanda), sin servicios gestionados, con la misma administración de siempre. Es el escenario donde la factura decepciona —y el punto de partida del que hablamos en FinOps—.
Replatforming: más esfuerzo, menos costo después
Replatformar es adaptar la carga para aprovechar la nube sin reescribirla desde cero. Ejemplos concretos: pasar tu base de datos a una base gestionada (el proveedor se encarga de parches, respaldos y alta disponibilidad), usar escalado automático para pagar solo por la capacidad que la demanda pide en cada momento, o mover archivos a almacenamiento de objetos por niveles en vez de discos siempre encendidos. Cuesta más trabajo al inicio, pero baja el costo operativo y mejora rendimiento y resiliencia. Es la diferencia entre estar en la nube y usar la nube.
Cuándo cada camino (no es o uno u otro)
La respuesta madura combina ambos según la carga y el horizonte:
- Lift-and-shift cuando urge salir de un datacenter (fin de contrato, hardware que muere), como primera etapa para migrar rápido y optimizar después, o para cargas que se van a jubilar pronto.
- Replatforming para lo que se va a quedar años y justifica la inversión —ahí es donde la nube empieza a pagar—.
Un patrón sensato: rehost primero para salir del apuro, y replatform después lo que lo amerite. Lo que no funciona es migrar todo a lo bruto y olvidarlo.
Nada de esto sobre terreno sin urbanizar
Ambos caminos se ejecutan mucho mejor sobre una landing zone ya ordenada, y ambos deben revisarse contra los pilares de Well-Architected. Y recuerda que no todo tiene que irse: parte puede quedarse on-premise con criterio. La estrategia de migración es una decisión por carga, no una bandera para toda la empresa.
La pregunta que conviene hacerse
Antes de migrar, la pregunta no es "¿lo muevo?", sino ¿esta carga se va a quedar años —y entonces vale replatformarla— o solo necesito salir rápido de donde está hoy? Y una segunda: ¿estoy dispuesto a pagar precios de nube por una VM que se comporta como servidor físico? Definir esa estrategia carga por carga es parte de cómo abordamos la migración a la nube.