El lift-and-shift mueve una aplicación a la nube tal cual, sin cambios de código: rápido y barato de migrar. La rearquitectura reconstruye la app alrededor de servicios cloud-native para menor costo de operación, mejor escala y resiliencia. La decisión de lift and shift vs refactor es un intercambio entre velocidad de migración hoy y eficiencia de operación mañana.
La mayoría de los equipos tratan esto como una sola gran decisión. No lo es. La tomas por carga de trabajo, y una buena migración normalmente mezcla ambas.
Lift-and-shift vs refactor: la diferencia central
Estas son dos de las "6 R" de la migración a la nube, y se ubican en extremos opuestos de esfuerzo y retorno:
- Lift-and-shift (rehospedar): copia la app y sus VMs a la nube sin cambios. Menor esfuerzo, menor riesgo de migración, salida más rápida del sitio. Conservas tu arquitectura existente, y sus ineficiencias.
- Rearquitectura (refactorizar): rediseña la app para usar bases de datos administradas, contenedores, serverless y autoescalado. Mayor esfuerzo, mayor retorno. Te quitas viejas restricciones y pagas por lo que de verdad usas.
Entre ellas se ubica el replataformado ("lift, tinker, and shift"): pequeñas optimizaciones como cambiar una base de datos autoadministrada por una administrada, sin una reescritura completa. Muchas cargas de trabajo caen aquí.
Lift-and-shift (rehospedar)
- sin cambios de código, salida más rápida del sitio
- menor costo inicial y riesgo de migración
- carga las ineficiencias existentes a una factura medida por uso
- mejor para fechas límite y apps estables de poco cambio
Rearquitectura (refactorizar)
- reconstruida alrededor de servicios administrados, contenedores y serverless
- mayor esfuerzo inicial, menor costo de operación a escala
- beneficios cloud-native completos como autoescalado
- mejor para apps centrales, de alto crecimiento y caras de operar
El intercambio, lado a lado
| Lift-and-shift (rehospedar) | Replataformar | Rearquitectura (refactorizar) | |
|---|---|---|---|
| Cambios de código | Ninguno | Mínimos | Significativos |
| Tiempo de migración | El más rápido | Medio | El más lento |
| Costo y riesgo inicial | El más bajo | Bajo–medio | El más alto |
| Costo mensual de operación | A menudo más alto | Más bajo | El más bajo a escala |
| Beneficios cloud-native | Pocos | Algunos | Completos (autoescalado, administrados, serverless) |
| Mejor para | Fechas límite, apps estables | Triunfos rápidos | Apps centrales de alto crecimiento |
El patrón: el lift-and-shift gana la migración, la rearquitectura gana la operación. El movimiento más barato de hoy puede volverse la factura más cara del año que viene si la carga de trabajo es intensa e ineficiente.
Cuándo el lift-and-shift es la decisión correcta
Rehospedar es el default inteligente cuando la velocidad y la certeza importan más que la optimización:
- Una fecha límite dura — un contrato de centro de datos que termina o un acuerdo que expira.
- Apps estables de poco cambio que no vale la pena reingeniar.
- Capacidad de ingeniería limitada para tomar una reescritura justo ahora.
- Reducir riesgo — sal del sitio primero, optimiza una vez que estés en la nube.
La trampa oculta: el lift-and-shift carga tu viejo sobredimensionamiento a un entorno medido por uso. Un servidor que corría al 15% de utilización en sitio sigue facturando 24/7 en la nube. Sin un ajuste posterior, la factura puede trepar.
Cuándo la rearquitectura se paga
Refactorizar se gana su costo cuando la carga de trabajo es central, creciente o cara de operar:
- Apps de alto tráfico donde el autoescalado y serverless recortan el gasto ocioso.
- Sistemas centrales en los que invertirás por años: vale la pena una base cloud-native.
- Apps que necesitan elasticidad — demanda con picos que los servidores fijos manejan mal.
- Presión de costo — una factura de nube creciente que los servicios administrados y de escala a cero pueden recortar.
Aquí es donde importan el FinOps y el DevOps continuos: CI/CD, infraestructura como código y monitoreo de costos convierten una app rearquitecturada en una que de verdad es más barata de operar, no solo más nueva.
Una rúbrica de calificación por carga de trabajo
No elijas una sola estrategia para todo el patrimonio: califica cada app. Califica cada carga de trabajo del 1 al 3 en los cinco factores de abajo, luego lee el total: entre más sube, más se paga la rearquitectura; un total bajo significa rehospeda ahora y revísalo después. Esta rúbrica es lo que convierte "lift and shift vs refactor" de una discusión en una decisión repetible que puedes correr en cien apps.
| Factor | Rehospedar (puntaje 1) | Replataformar (puntaje 2) | Rearquitectura (puntaje 3) |
|---|---|---|---|
| Presión de fecha límite | Fecha dura, a semanas | Algo de flexibilidad | Sin fecha fija |
| Ritmo de cambio | Estable, casi no se toca | Actualizaciones ocasionales | Evolucionando activamente |
| Costo de operación y tráfico | Bajo, predecible | Moderado | Alto y con picos |
| Criticidad de negocio | Periférica, de corta vida | Importante | Crítica para la misión, de larga vida |
| Capacidad de ingeniería | Nada de sobra | Algo | Financiada para una reescritura |
Lee el total a lo largo de los cinco factores:
- 5–7 → Rehospedar. Llévalo a la nube tal cual; optimiza después si se lo gana.
- 8–11 → Replataformar. Pequeños ajustes cloud-native para un retorno rápido.
- 12–15 → Rearquitectura. La carga de trabajo justifica una reconstrucción cloud-native.
Un plan de migración común en Estados Unidos: rehospeda para llegar a la fecha límite, luego rearquitectura los pocos mayores impulsores de costo o tráfico una vez que están corriendo en la nube. Repartes el costo y el riesgo, siempre y cuando de verdad financies la fase dos. Si prefieres no correr la rúbrica solo, los servicios de migración a la nube neutrales al proveedor pueden calificar el patrimonio contigo y hacerse cargo de la secuencia rehospedar-y-refactorizar de punta a punta.
En resumen
Lift and shift vs refactor no es una decisión de todo o nada, es una decisión de portafolio. El lift-and-shift te lleva a la nube rápido y barato; la rearquitectura te hace más barato y más ágil de operar una vez que estás ahí. La mayoría de los equipos mezclan las dos: rehospeda la cola larga, rearquitectura las cargas de trabajo que mueven la factura. Si quieres ayuda calificando tu patrimonio carga por carga, eso es justo lo que hace nuestro equipo de servicios de migración a la nube neutral al proveedor —en AWS, Azure y GCP, con ingenieros nearshore senior en tu zona horaria desde Monterrey y a tarifa fija, no una casa offshore en India o Dubái con un retraso de doce horas. Tú eres dueño de las cuentas de nube y del código reconstruido por completo.
