Las 7 R son el menú estándar de enfoques de modernización de sistemas legacy: retener, retirar, rehospedar, replataformar, refactorizar, rearquitecturar y reconstruir. Van desde dejar un sistema intacto hasta construir uno nuevo desde cero, y la mayoría de los programas reales usan varias a lo largo de un portafolio, no solo una.
Elegir la R correcta para cada sistema es todo el juego. Elige un enfoque demasiado ligero y cargas los mismos problemas a la nueva infraestructura; elige uno demasiado pesado y te pasas un año reconstruyendo lógica que ya funcionaba. Esta guía explica cada una de las siete, cuánto cuesta en riesgo y cómo decidir.
¿Qué son los enfoques de modernización legacy?
Un enfoque de modernización es la estrategia que aplicas a un sistema viejo para hacerlo encajar en un stack moderno: no una sola herramienta, sino una decisión sobre qué tan lejos cambiar la cosa. Las 7 R (una extensión de las 5 R originales de Gartner) le dan a esa decisión un vocabulario compartido, así que "estamos replataformando el sistema de facturación pero refactorizando el motor de pedidos" significa lo mismo para todos en la sala.
Las R se ubican en un espectro de esfuerzo y riesgo. La primera pregunta no es cómo modernizar un sistema, sino si hacerlo y qué tan lejos.
Las 7 R de la modernización
Aquí está el menú completo, ordenado de menor a mayor esfuerzo:
| Enfoque | Qué significa | Esfuerzo y riesgo | Mejor cuando |
|---|---|---|---|
| Retener | Déjalo como está, revísalo después | Ninguno | El sistema funciona y no hay razón apremiante para tocarlo |
| Retirar | Dale de baja por completo | Bajo | La capacidad es redundante, no se usa o ya está reemplazada |
| Rehospedar | Lift and shift a nueva infra, sin cambiar código | Bajo | Necesitas hospedaje más barato o en la nube rápido, el código está bien |
| Replataformar | Mover con ajustes menores (ej. BD administrada) | Bajo–medio | Cambios pequeños desbloquean beneficios reales de hospedaje o costo |
| Refactorizar | Reescribir las entrañas, mismo comportamiento | Medio | La lógica es valiosa pero el código es difícil de mantener |
| Rearquitecturar | Reestructurar el sistema (ej. a microservicios) | Alto | La arquitectura misma bloquea la escala o el cambio |
| Reconstruir | Construirlo nuevo desde cero | El más alto | La lógica ya no encaja y la tecnología es insostenible |
Los dos extremos son fáciles: retener y retirar no necesitan ingeniería. El centro es donde vive el criterio, y donde de verdad pasa el trabajo del servicio de modernización de sistemas legacy.
Retener y retirar — los triunfos más baratos
La modernización más rápida muchas veces es no modernizar. Retén los sistemas que funcionan y no bloquean nada; gasta tu presupuesto donde mueve la aguja. Retira todo lo redundante: cada sistema que apagas es uno que nunca tendrás que migrar, asegurar ni dotar de personal. Auditar para estas dos primero encoge el resto del programa.
Rehospedar y replataformar — muévelo, casi como está
Rehospedar (lift and shift) mueve una aplicación a nueva infraestructura, normalmente la nube, sin cambiar código. Es el camino más rápido para salir de hardware que falla o un centro de datos caro. Replataformar da un pequeño paso más —cambiar a una base de datos administrada o un runtime de contenedores— para capturar beneficios de nube que el lift puro deja sobre la mesa. Ambos son de bajo riesgo porque el comportamiento de la aplicación no cambia.
Refactorizar y rearquitecturar — cambia el interior
Refactorizar reescribe las entrañas de un sistema para mejorar la estructura, el desempeño o la mantenibilidad, conservando el mismo comportamiento. Rearquitecturar va más profundo, rediseñando cómo está organizado el sistema; por ejemplo, partiendo un monolito en servicios. Estas cuestan más y cargan más riesgo, pero son la forma de hacer un sistema viejo valioso genuinamente moderno en lugar de solo reubicado.
Reconstruir — el último recurso
Reconstruir significa escribir el sistema de nuevo. Es el más caro y riesgoso de los enfoques de modernización, así que se gana su lugar solo cuando la lógica de negocio misma ya no encaja o la tecnología subyacente es insostenible. El error que cometen los equipos es echar mano de la reconstrucción por default, y tirar a la basura años de lógica ganada a pulso que un refactor habría conservado.
Cómo elegir el enfoque correcto
Califica cada sistema en tres ejes, luego empátalo con la R más ligera que cumpla la meta:
- Valor de negocio — cuánto depende la empresa de él. Un valor alto justifica más inversión.
- Salud técnica — qué tan mantenible, seguro y sostenible son el código y el stack.
- Riesgo y urgencia — qué se rompe, y qué tan pronto, si no haces nada.
Los sistemas de bajo valor o redundantes se retiran. Los sistemas sanos que solo necesitan mejor economía se rehospedan o replataforman. Los sistemas de alto valor con malas entrañas se refactorizan o rearquitecturan. Solo los pocos donde la lógica es el problema se reconstruyen. Corre esto a lo largo de todo el portafolio y la mezcla correcta de enfoques cae por su propio peso.
De los enfoques a las estrategias de modernización
Las 7 R son los enfoques; una estrategia de modernización es cómo los secuencias a lo largo de todo el patrimonio de sistemas. Las estrategias de modernización legacy convierten esta calificación por sistema en un plan por etapas: qué modernizar primero, qué envolver detrás de APIs y qué retirar, para que el negocio siga corriendo mientras el portafolio evoluciona. Los enfoques responden "¿qué tanto cambiamos este sistema?"; la estrategia responde "¿en qué orden y a qué costo?". Para el manual completo, consulta nuestra guía de estrategia de modernización legacy, y cuando la decisión sea entre actualizar y empezar de nuevo, nuestro desglose de modernizar vs reconstruir.
Modernizar sin apostar el negocio
La parte más riesgosa de cualquier enfoque no es el código, es el cambio de switch. Un cambio de un solo golpe puede tirar las operaciones. El patrón más seguro, y el que usamos, es incremental: envuelve el sistema legacy en APIs, moderniza una capacidad a la vez detrás de una frontera estable y conserva un rollback en cada etapa. Este método strangler-fig deja que el sistema viejo siga corriendo en producción mientras el nuevo crece a su lado, así el negocio nunca se queda a oscuras.
También es la razón por la que las personas importan tanto como el plan. La modernización necesita ingenieros fluidos tanto en stacks viejos —COBOL, mainframe, frameworks anticuados— como en herramientas modernas de nube e IA. Un equipo nearshore senior en México, trabajando en horario laboral de Estados Unidos desde Monterrey, mantiene ese constante ciclo de evaluar-envolver-migrar en tiempo real, más ágil y de menor costo que un integrador de sistemas empresarial. La IA ahora acelera la lectura y documentación del código legacy, pero el criterio sobre qué R aplicar sigue siendo humano.
En resumen
Las 7 R no son un ranking, son una caja de herramientas. Los mejores enfoques de modernización legacy para tu portafolio casi siempre son una mezcla: retira el peso muerto, rehospeda lo que solo necesita mejor hospedaje, refactoriza lo valioso pero frágil y reconstruye solo donde la lógica misma dejó de encajar. Decide sistema por sistema, moderniza de forma incremental y mantén el negocio corriendo todo el camino.
