Rehost, replatform o refactor: qué estrategia elegir

Son estrategias con compromisos distintos

Los términos describen cuánto cambia una carga durante la migración. En la práctica puede haber varias estrategias en una misma cartera, e incluso una carga que cambie de estrategia a lo largo del tiempo. AWS resume un conjunto de opciones en su guía de estrategias de migración; el vocabulario varía entre proveedores, así que define el alcance técnico en lugar de depender solo de una etiqueta.

Estrategia	Qué cambia	Puede encajar cuando…	Compromiso principal
Rehost	Se mueve la aplicación con cambios mínimos	Hay urgencia, compatibilidad y se necesita reducir cambios durante el traslado	Se conservan limitaciones y trabajo operativo existentes
Replatform	Se realizan ajustes acotados en plataforma o configuración	Un servicio gestionado reduce una carga concreta y la aplicación puede adaptarse	Aparecen cambios de compatibilidad, operación y dependencia del servicio
Refactor / re-architect	Se modifica arquitectura y código de forma sustancial	Hay objetivos que no se alcanzan con un traslado o adaptación menor	Mayor esfuerzo, pruebas y riesgo de alcance

Decide por carga, no por eslogan

Evalúa cada aplicación con estas preguntas:

1. ¿Qué objetivo impulsa el cambio: soporte, continuidad, coste, capacidad, rendimiento o velocidad de entrega?
2. ¿Qué restricciones impone la base de datos, el sistema operativo, la licencia o una integración externa?
3. ¿Qué cambio mínimo permite cumplir el objetivo y cómo se medirá?
4. ¿Hay pruebas y observabilidad suficientes para detectar regresiones?
5. ¿Puede el equipo operar la nueva plataforma y recuperar el servicio?
6. ¿Qué coste y riesgo crea mantener temporalmente la arquitectura actual?

Si solo necesitas retirar hardware y la aplicación funciona de forma estable, rehost puede ser una etapa razonable. Si una base de datos gestionada reduce tareas de parcheo y existe compatibilidad confirmada, replatform puede tener sentido. Si el diseño impide escalar una función crítica o cambiar componentes con seguridad, refactor podría abordar la causa; exige un caso y un plan de pruebas.

Evita los extremos automáticos

Rehost no es siempre una solución temporal ni siempre la más barata: puede ser el destino adecuado para una carga que se retirará pronto, o una primera etapa para reducir exposición. Refactor tampoco garantiza menor coste o mejor rendimiento; una arquitectura nueva introduce operación y dependencias que deben estimarse.

No elijas una estrategia únicamente por la etiqueta «Cloud native». Decide qué propiedad necesitas y qué evidencia demostrará que se obtuvo. Si el objetivo es mejorar tiempos, define una medición representativa; si es reducir trabajo operativo, identifica tareas que desaparecen y las nuevas que aparecen.

Usa una estrategia por etapas

Una secuencia frecuente es trasladar con cambios acotados, estabilizar, observar y modernizar una parte concreta con datos de uso. Puede ayudar a separar riesgos, aunque también genera coste de transición y no es adecuada para todas las aplicaciones. Define condiciones de salida: estabilidad, costes observados, calidad de datos, plan de reversión y capacidad de operación.

Registra la decisión junto a dependencias, responsables, supuestos y fecha de revisión. Reconsidera la estrategia si cambian las necesidades de negocio o aparece evidencia que invalida el caso inicial.