Rehost, replatform o refactor: cómo elegir la estrategia de migración a AWS
La pregunta «¿cómo migramos a AWS?» no tiene una respuesta, tiene seis — y lo habitual es que en una misma empresa convivan tres o cuatro al mismo tiempo, una por sistema. Elegir mal no rompe la migración: la vuelve el doble de cara o deja intactos los problemas que se quería resolver. Este artículo explica cada opción por lo que exige y lo que devuelve, y da criterios para decidir sin depender de la intuición.
Primero: no se elige una para todo
El error más frecuente es tratar la migración como una decisión única. «Vamos a migrar a AWS» se traduce en la práctica a decidir, sistema por sistema, qué se hace con cada uno.
Una empresa con doce sistemas puede terminar apagando tres, moviendo cinco tal cual, mejorando tres al pasarlos y dejando uno donde está. Ese reparto es la estrategia de migración. Cualquier propuesta que aplique la misma receta a todo el inventario está simplificando algo que no se puede simplificar.
Las seis estrategias, por esfuerzo y retorno
| Estrategia | Esfuerzo | Beneficio |
|---|---|---|
| Rehost «levantar y mover» | Bajo | Bajo a medio |
| Replatform «mover y mejorar un poco» | Medio | Medio a alto |
| Refactor «rediseñar» | Alto | Alto, pero a plazo |
| Repurchase «cambiar por un producto» | Variable | Alto si encaja |
| Retain «dejarlo donde está» | Ninguno | Evita gasto inútil |
| Retire «apagarlo» | Ninguno | Ahorro inmediato |
Cuándo corresponde cada una
Rehost «levantar y mover»
Se mueve el servidor tal cual está a una instancia EC2, sin tocar la aplicación ni el sistema operativo.
Cuándo: Hay una fecha límite dura —un contrato de datacenter que vence, un equipo que se muere—, o el sistema es una caja negra que nadie sabe modificar.
Ojo con: Sale de la nube todo lo que estaba mal en el servidor viejo. Si estaba sobredimensionado, vas a pagar por ese exceso todos los meses.
Replatform «mover y mejorar un poco»
Se mueve la aplicación pero se cambian piezas de infraestructura por servicios administrados: la base de datos pasa a RDS, los archivos a S3, el balanceo a un ELB.
Cuándo: La aplicación funciona bien y no querés reescribirla, pero sí dejar de administrar el motor de base de datos y los respaldos a mano.
Ojo con: Es donde mejor suele quedar la relación entre trabajo y resultado, y por eso es lo más frecuente en una PYME.
Refactor «rediseñar»
Se reescriben partes de la aplicación para aprovechar la nube: contenedores, funciones sin servidor, colas, separación en servicios.
Cuándo: La arquitectura actual ya es el problema — no escala, cada despliegue es riesgoso, o el costo crece más rápido que el uso.
Ojo con: Es el único que puede cambiar de verdad la economía del sistema, y también el único que puede descarrilar un proyecto. No se hace durante la migración: se hace después, y por partes.
Repurchase «cambiar por un producto»
Se abandona el sistema propio y se contrata un producto que hace lo mismo.
Cuándo: Lo que mantenés no te diferencia de nadie: un CRM hecho en casa, una intranet, un gestor documental.
Ojo con: La migración de datos y el cambio de hábitos suelen costar más que la licencia. El ahorro real aparece en el segundo año.
Retain «dejarlo donde está»
Se decide conscientemente no migrar ese sistema, por ahora.
Cuándo: Hay una restricción legal, una dependencia de hardware específico, o el sistema se va a jubilar en un año y no vale la pena moverlo.
Ojo con: Es una decisión válida, no una derrota. Lo importante es que quede escrita con su razón y una fecha de revisión.
Retire «apagarlo»
Se apaga porque ya nadie lo usa.
Cuándo: El inventario revela servidores que nadie reclama. Aparecen en casi todas las revisiones iniciales.
Ojo con: Es la estrategia más rentable del listado y la que más se pasa por alto. Cada sistema que no migrás es trabajo que no hacés y factura que no pagás.
Cuatro preguntas que resuelven casi todos los casos
Para cada sistema del inventario, en este orden. La primera que dé un «sí» claro suele definir la decisión.
1. ¿Alguien lo usa todavía?
Mirá accesos y tráfico de los últimos meses, no la opinión de nadie. Si no lo usa nadie: retire. Empezar por acá reduce el alcance del proyecto antes de gastar un peso.
2. ¿Esto te diferencia de tu competencia?
Si es un CRM genérico, una intranet o un gestor de archivos, probablemente exista un producto que lo hace mejor: repurchase. Mantener software propio que no te distingue es un costo permanente sin retorno.
3. ¿La arquitectura actual es el problema?
Si no escala, si cada despliegue da miedo o si el costo crece más rápido que el uso, mover el problema a AWS no lo arregla: refactor. Pero hacelo después de migrar, no durante — mezclar las dos cosas es la forma más común de que un proyecto se estire al doble.
4. ¿Hay una fecha que no se puede mover?
Un contrato que vence o hardware que falla obliga a rehost: salir primero, optimizar después. Si no hay presión de fecha, replatform casi siempre paga mejor.
La trampa del rehost puro
Mover todo tal cual es tentador: es lo más rápido, lo más barato de ejecutar y lo que menos discusión genera. El problema aparece en la primera factura.
Un servidor físico se compra una vez y luego se olvida; que esté sobredimensionado no duele todos los meses. En la nube sí. Un equipo comprado con margen para cinco años de crecimiento, replicado tal cual en una instancia EC2, factura ese margen cada mes desde el primer día.
Por eso, si elegís rehost por una fecha límite, conviene dejar agendada la revisión de dimensionamiento para las semanas siguientes al cutover — cuando ya tenés métricas reales de uso en AWS y podés ajustar con datos en vez de suposiciones.
Cómo se ve esto en un plan real
Una vez asignada la estrategia a cada sistema, la migración se ordena en olas — grupos que se mueven juntos porque comparten dependencias. Suele funcionar así:
- Ola cero: apagar lo que nadie usa. Sin riesgo y reduce todo lo que viene después.
- Primera ola: sistemas secundarios o entornos de prueba. Sirven para validar el procedimiento donde un error no cuesta caro.
- Olas intermedias: producción, de menor a mayor criticidad, validando cada una antes de seguir.
- Última ola: el sistema del que depende todo lo demás. Se migra al final, con el equipo ya entrenado por las olas anteriores.
- Después: ajuste de dimensionamiento y los refactor que se hayan decidido, ya sin la presión del cutover.
Para bases de datos, la replicación continua permite mantener el origen activo hasta el corte final, de modo que la ventana de indisponibilidad se mide en minutos y no en horas.
Si tenés el inventario pero no sabés qué estrategia le corresponde a cada sistema, esa es exactamente la conversación de un Migration Readiness Assessment.
Solicitar un Migration Readiness Assessment