Migración de Aplicaciones

Resumen rápido

Concepto	Definición breve
Migración de aplicaciones	Proceso de mover una aplicación de un entorno a otro (físico → nube, versión antigua → nueva, etc.)
Objetivo	Mejorar rendimiento, reducir costes, modernizar tecnología o eliminar deuda técnica
Decisión clave	Elegir la modalidad adecuada según coste, riesgo y valor esperado

Las 8 Modalidades (Las "8 R")

Modalidad	También llamada	Cambio en código	Complejidad	Objetivo principal
Rehosting	Lift & Shift	❌ Mínimo	🟢 Baja	Mover sin tocar
Replatforming	Lift, Tinker & Shift	⚠️ Parcial	🟡 Media	Optimizar en nueva plataforma
Refactoring	Re-architecting	✅ Profundo	🔴 Alta	Rediseñar arquitectura
Refronting	—	⚠️ Solo frontend	🟡 Media	Modernizar interfaz
Replacement	—	❌ Se abandona	🟡 Media	Sustituir por solución nueva
Repurchasing	—	❌ Se abandona	🟢 Baja	Comprar producto de mercado (SaaS)
Retaining	—	❌ Ninguno	🟢 Baja	No migrar (por ahora)
Retiring	—	❌ Ninguno	🟢 Baja	Dar de baja la aplicación

Detalle de cada modalidad

Rehosting — Lift and Shift

Mover la aplicación tal cual a otra infraestructura (p. ej., de servidores físicos a nube) sin modificar el código.

Ventaja: rápido, bajo riesgo, mínimo coste de desarrollo.
Inconveniente: no aprovecha las capacidades nativas del nuevo entorno.
Cuándo usarlo: necesidad urgente de salir de un CPD, fin de contrato de hardware.

Replatforming — Lift, Tinker & Shift

Migrar realizando ajustes menores para que la aplicación funcione mejor en la nueva plataforma, sin rediseñarla.

Ejemplo: cambiar la base de datos a un servicio gestionado en la nube, ajustar configuraciones de despliegue.
Cuándo usarlo: cuando hay ganancias fáciles de rendimiento sin rediseño.

Refactoring / Re-architecting

Modificar en profundidad el código o la arquitectura para adaptarse al nuevo entorno, mejorar escalabilidad o eliminar deuda técnica.

Ejemplo: pasar de una aplicación monolítica a microservicios.
Cuándo usarlo: cuando la aplicación tiene problemas estructurales que limitan su evolución.

Refronting

Cambiar o modernizar la capa de presentación (UI/UX) manteniendo la lógica interna y el backend.

Ejemplo: reescribir la interfaz en React manteniendo el mismo backend.
Cuándo usarlo: cuando el backend es sólido pero la interfaz está obsoleta.

Replacement

Sustituir la aplicación antigua por una nueva solución desarrollada a medida o estándar, en lugar de migrar la existente.

Cuándo usarlo: cuando la aplicación es inviable de mantener o migrar, y existe una alternativa mejor.

Repurchasing

Abandonar la aplicación actual y adquirir un producto ya existente en el mercado (frecuentemente SaaS) que cubra la misma necesidad.

Ejemplo: pasar de un CRM propio a Salesforce.
Cuándo usarlo: cuando el mercado ofrece soluciones maduras y el mantenimiento propio no aporta valor diferencial.

Retaining

No migrar la aplicación, al menos por el momento, porque sigue siendo útil o porque migrarla no compensa el esfuerzo.

Cuándo usarlo: aplicaciones críticas con alta complejidad técnica, bajo ROI esperado de la migración o dependencias difíciles de resolver.

Retiring

Dar de baja la aplicación porque ya no aporta valor, ha quedado obsoleta o sus funciones ya no son necesarias.

Cuándo usarlo: duplicidades con otros sistemas, funcionalidades sin uso demostrable, final de ciclo de vida.

Diagrama de decisión

¿La aplicación sigue aportando valor?
         │
    NO ──┴──► Retiring
         │
        SÍ
         │
¿Se debe migrar ahora?
         │
    NO ──┴──► Retaining
         │
        SÍ
         │
¿Se puede sustituir por un producto de mercado?
         │
        SÍ ──► Replacement / Repurchasing
         │
        NO
         │
¿Solo hay que cambiar la interfaz?
         │
        SÍ ──► Refronting
         │
        NO
         │
¿Hace falta cambiar código?
         │
    NO ──┴──► Rehosting (Lift & Shift)
         │
  Ajustes menores ──► Replatforming
         │
  Cambios profundos ──► Refactoring / Re-architecting

Tabla comparativa ampliada

Modalidad	Coste	Riesgo	Tiempo	Beneficio tecnológico
Rehosting	💰 Bajo	🟢 Bajo	⚡ Rápido	Bajo
Replatforming	💰💰 Medio	🟡 Medio	🕐 Medio	Medio
Refactoring	💰💰💰 Alto	🔴 Alto	🕐🕐 Largo	Muy alto
Refronting	💰💰 Medio	🟡 Medio	🕐 Medio	Medio (solo UI)
Replacement	💰💰💰 Alto	🔴 Alto	🕐🕐 Largo	Alto
Repurchasing	💰💰 Medio	🟡 Medio	⚡ Rápido	Alto (SaaS)
Retaining	💰 Nulo	🟢 Nulo	—	Nulo
Retiring	💰 Nulo	🟢 Nulo	⚡ Rápido	Eliminación deuda técnica

⚠️ Conceptos que confunden en examen

Replacement vs Repurchasing: ambos implican abandonar la app actual, pero Replacement puede ser una solución nueva a medida, mientras que Repurchasing es específicamente adquirir un producto ya existente en el mercado (SaaS o similar).
Rehosting vs Replatforming: el límite está en si se tocan o no los componentes de la aplicación; en Rehosting no se toca nada, en Replatforming se hacen ajustes menores.
Refactoring vs Replatforming: Replatforming es superficial (configuración, infraestructura); Refactoring implica rediseño del código o la arquitectura.

Resumen en 3 puntos

Las 8 modalidades de migración (las "8 R") cubren todo el espectro desde no hacer nada (Retaining/Retiring) hasta rediseñar completamente (Refactoring), pasando por mover sin cambios (Rehosting) o sustituir por soluciones de mercado (Repurchasing).
La elección de modalidad depende del equilibrio entre coste, riesgo, tiempo disponible y el beneficio tecnológico esperado; no existe una opción universalmente mejor.
En contexto de oposiciones, se suele preguntar la diferencia entre modalidades similares: Replacement vs Repurchasing, Rehosting vs Replatforming, y el criterio para elegir Retiring frente a Retaining.