Estimated reading time: 13 minutos
Toda institución con sistemas legados necesita tomar una decisión en cada uno de ellos: mantener, aislar, modernizar o sustituir. Esa elección dirige el capital de los próximos años, define dónde concentrarán esfuerzo los equipos y determina cuánto riesgo carga la operación durante la transición.
Cada camino tiene un costo distinto:
- Sustituir un sistema que todavía cumple su papel consume capital sin crear ventaja competitiva;
- Mantener un sistema que ya limita la operación posterga la inversión y empuja el costo hacia el próximo incidente;
- Aislar sin definir claramente sus fronteras puede solo desplazar la complejidad hacia otras partes de la arquitectura;
- Modernizar el legado sin medir dependencias y acoplamiento aumenta el riesgo de descubrir el alcance completo recién después de iniciado el proyecto.
Este artículo transforma esa decisión en criterios medibles. Muestra qué indicadores apuntan a mantener, aislar, modernizar o sustituir cada sistema, y cómo registrar la elección para orientar inversión, ejecución y gobernanza.
Qué métricas revelan la deuda de un sistema legado
Evaluar un sistema legado va más allá de la mera impresión de obsolescencia. Un sistema no es legado solo porque el lenguaje envejeció, el equipo original salió o falta documentación.
El peso del legado puede medirse con datos de la operación: costo y frecuencia de incidentes en producción, tiempo para poner una funcionalidad nueva en el aire y tasa de retrabajo por fallas estructurales. Otro indicador es cuánto depende la operación del conocimiento de pocas personas. Cuando ese conocimiento queda concentrado, la ausencia de una persona puede trabar la operación.
La diferencia de percepción aparece en los datos. El informe 2025 Architecture in Software Development, investigación independiente encargada por vFunction, encuestó a 629 líderes y profesionales de tecnología en Estados Unidos y el Reino Unido. Entre el liderazgo ejecutivo, 52% afirma que la documentación de arquitectura corresponde a lo que corre en producción. Entre profesionales de ingeniería y arquitectura, ese número baja a 36%. Quien decide sobre el sistema puede estar trabajando con una visión distinta de quien lo maneja en el día a día.
Eso, por sí solo, no significa que el sistema sea inestable o caro de operar. Antigüedad tecnológica y deuda técnica son cosas distintas. La antigüedad es neutra. La deuda técnica empieza a importar cuando aumenta costos, reduce la velocidad de entrega o eleva el riesgo de la operación.
Por eso la decisión debe partir de métricas, no de percepción. Esos datos suelen existir ya en el ambiente: en herramientas de integración continua (CI), registros de incidentes y prorrateos de costo.
| Categoría | Qué medir | Dónde ya existe el dato |
| Entrega | Frecuencia de deploy, lead time de cambio, tiempo de recuperación de deploy fallido, tasa de falla en cambio y tasa de retrabajo de deploy, las cinco métricas actuales de software delivery performance de DORA | Pipeline de CI y registro de releases |
| Confiabilidad | Disponibilidad contra los SLOs acordados, MTTR, volumen y severidad de incidentes atribuidos al sistema | Herramienta de incidentes y panel de SLO |
| Riesgo estructural | Blast radius (cuántos sistemas se detienen si este se detiene), número de integraciones, concentración de conocimiento (bus factor), componentes sin soporte, CVEs conocidos | Mapa de dependencias e inventario de versiones |
| Economía | Costo anual de mantenimiento contra costo de evolución, licenciamiento, infraestructura, costo de especialistas escasos | Prorrateo de infraestructura y asignación de equipo |
La transición ocurre cuando la deuda pasa a consumir la capacidad de entrega. Incluso sin reclamos explícitos, un sistema de bajo desempeño limita directamente la velocidad del negocio.
Qué camino pide cada perfil de sistema legado
El error clásico reduce la decisión a refactorizar contra reescribir. El aislamiento merece figurar entre las opciones reales, porque es la decisión más frecuente en la práctica.
- Mantener: Seguir operando sin inversión de evolución. Indicado para un sistema estable, comoditizado, con bajo costo de operación y sin demanda de cambio.
- Aislar: Encapsular el sistema detrás de una interfaz con contrato de integración, límites y monitoreo, e integrar por ahí de ahí en adelante. Cabe a sistemas de alto valor expuestos de forma riesgosa, con gran radio de impacto a contener. Patrones establecidos para esto incluyen encapsulamiento, el Strangler Fig Pattern y una capa anticorrupción.
- Modernizar: Evolucionar por etapas, con refactorización, replatform o nueva arquitectura de partes del sistema, preservando la operación. Es la elección para un sistema que sostiene ingresos y necesita cambiar con frecuencia.
- Sustituir: Construir o adquirir un sistema nuevo y apagar el actual. Se justifica cuando el legado bloquea una capacidad crítica que el negocio necesita ofrecer y ninguna evolución incremental entrega ese resultado.
La regla de ordenamiento es simple: elegir el camino de menor riesgo que resuelve el problema. La sustitución tiende a concentrar más riesgo de ejecución y de transición, razón por la cual normalmente debe considerarse después de las alternativas incrementales.
Para el caso extremo existe un umbral objetivo, propuesto por McKinsey en un estudio con 50 CIOs de servicios financieros y tecnología (2020).
Cuando la deuda técnica de un área supera 50% del valor de su activo tecnológico, el riesgo y el costo de los sistemas actuales empiezan a superar el beneficio, y la construcción de un stack nuevo entra en discusión.
Tech debt: Reclaiming tech equity
El mismo estudio recomienda evitar el enfoque big bang, porque los megaproyectos de TI concentran riesgo de ejecución y traban la capacidad de competir mientras están en curso.
Cómo leer los números y elegir entre aislar y sustituir
| Lectura predominante | Camino indicado |
| Métricas de entrega estables, costo bajo, ninguna demanda de cambio | Mantener |
| Alto valor, blast radius grande, necesidad de integrar sin reescribir | Aislar, empezando por las interfaces más críticas |
| Ingresos dependientes del sistema, lead time alto, cambio frecuente exigido | Modernizar por etapas |
| Capacidad de negocio bloqueada, sin camino incremental, componentes sin soporte | Sustituir, con plan de transición y operación en paralelo |
| Deuda por encima de la mitad del valor del activo del área | Evaluar un stack nuevo, con fases y sin big bang |
| Bus factor de uno, sin runbook | Tratar el riesgo antes de la arquitectura: runbook, redundancia de conocimiento y monitoreo |
Cuando queda un único especialista y ningún runbook, el riesgo operativo supera cualquier argumento sobre calidad de código. Ese riesgo entra en el precio de la decisión.
Señales de que la modernización está dando resultado
Cada camino tiene señal de acierto y señal de error. Seguir las dos evita que la elección se convierta en un proyecto sin fin.
| Camino | Señal de acierto | Señal de error |
| Mantener | Sigue económico, estable y sin incidentes atribuidos | Vulnerabilidad crítica sin corrección disponible |
| Aislar | Las integraciones nuevas entran sin tocar el núcleo | La capa de aislamiento se vuelve un segundo sistema a mantener |
| Modernizar | Las métricas DORA mejoran porción por porción | La migración se estanca y la empresa opera dos sistemas por tiempo indefinido |
| Sustituir | El sistema nuevo asume tráfico sin indisponibilidad | El alcance crece, el plazo se corre y no existe camino de rollback |
Por qué los agentes de IA cambian la urgencia de modernizar
La decisión de portafolio legado existe desde mucho antes de la IA agencial. Lo que cambió es el costo de postergarla.
La expectativa dominante va en dirección opuesta. En el mismo levantamiento, 65% cree que el desarrollo acelerado por IA simplificará la arquitectura de la empresa. El informe concluye lo contrario: código generado rápido, sin decisión arquitectónica detrás, acelera la fragmentación.
Ponga un agente a leer y escribir en ese sistema y hereda todo lo que existe adentro: dependencias que nadie documentó, interfaces frágiles, fallas que ocurren en silencio. A su velocidad, y a su escala.
Una persona que conoce las mañas del sistema las rodea y sigue. Un agente integrado sobre interfaces frágiles o comportamientos implícitos tiende a amplificar esos problemas: puede fallar, ejecutar una secuencia inesperada o producir un resultado difícil de auditar.
Gartner registra que integrar agentes con sistemas legados suele ser técnicamente complejo, con flujos de trabajo interrumpidos y modificaciones costosas (junio de 2025). El volumen de iniciativas agenciales que no llegan a producción está mapeado en Cómo escalar agentes de IA en bancos.
Las condiciones de abajo indican que un sistema existente soporta exposición a un agente con riesgo administrable:
- Interfaces explícitas y versionadas, con contrato de integración, sin acceso directo a la base de datos.
- Identidad máquina a máquina, con credencial de corta duración y menor privilegio.
- Operaciones críticas idempotentes o protegidas por clave de idempotencia.
- Límites transaccionales claros, de modo que el agente no deje el sistema en estado inconsistente.
- Logs, métricas y tracing suficientes para auditar y revertir lo que el agente hizo.
- Datos accesibles con gobernanza y clasificación definidas.
- Un camino de revocación rápida de credencial, con plazo acordado.
Un sistema que falla en esos ítems pide aislamiento antes de la exposición. La especificación del Model Context Protocol advierte que las herramientas expuestas a agentes pueden representar ejecución arbitraria de código y establece requisitos de consentimiento y control para su invocación. Por lo tanto, encapsular un legado sin contrato de integración, autorización, límites operativos y traza de auditoría solo desplaza el riesgo a una nueva capa.
La capa de identidad e integración que esos agentes atraviesan es el tema de Agentic Enterprise: identidad e integración de agentes de IA.
El costo de modernizar después de que el agente está en producción
| Camino | Alcance del trabajo | Qué se detiene | Evidencia exigida |
| Aislar la interfaz antes | Una capa de integración, con contrato de integración y límites definidos | Nada en producción | Mapa de acoplamiento del sistema |
| Pausar el proyecto en producción | Retrabajo de arquitectura, con el agente ya integrado | La iniciativa agencial y los flujos que toca | Investigación de incidente, con plazo de regulador |
El primer camino consume tiempo de planificación. El segundo consume presupuesto de ejecución, atención del liderazgo y confianza del equipo en el roadmap.
Cómo registrar la decisión de arquitectura para auditoría
Para que una decisión de arquitectura soporte una auditoría, debe registrar el sistema evaluado, las métricas y la fecha del análisis, el camino elegido y la persona responsable de la ejecución. Sin ese historial, la discusión se vuelve cíclica: en cada nuevo presupuesto reaparecen las mismas opiniones sin ningún dato nuevo para sustentar el avance.
Las empresas que tratan la deuda técnica como un desafío de negocio adoptan una práctica consolidada por McKinsey: cada aplicación se vincula a sus costos operativos y a su propósito estratégico. Así, la decisión de invertir, mantener o discontinuar un sistema queda formalmente registrada para cada activo.
Preguntas frecuentes
Aislar significa encapsular el sistema detrás de una interfaz con contrato de integración e integrar por ahí, sin alterar el núcleo. Modernizar significa evolucionar el propio sistema por etapas, con refactorización, replatform o nueva arquitectura de partes de él. El aislamiento contiene riesgo; la modernización cambia el sistema.
Las cinco métricas DORA para capacidad de entrega, cumplimiento de SLO y MTTR para confiabilidad, blast radius y bus factor para riesgo estructural, y costo de mantenimiento contra costo de evolución para economía. La antigüedad, aislada, no indica nada.
No. La antigüedad tecnológica es neutra. Lo que pesa es la deuda que afecta al negocio, medida en velocidad de entrega, confiabilidad, riesgo estructural y costo.
Según McKinsey, cuando la deuda técnica de un área supera 50% del valor de su activo tecnológico, el riesgo y el costo de los sistemas actuales empiezan a superar el beneficio. El mismo estudio recomienda fases en lugar de big bang.
Porque el agente hereda las dependencias y los modos de falla del sistema al que accede. Gartner registra que esa integración suele exigir modificaciones costosas e interrumpir flujos existentes. Decidir después traslada el costo a la ejecución, cuando corregir sale más caro.
Su desafío merece una conversación estratégica
La práctica de Modernización de Aplicaciones de TreeID conduce la revisión de arquitectura que produce esas métricas. Mapeamos acoplamiento y dependencias sistema por sistema. Evaluamos riesgo operativo contra el historial real de incidentes. Y entregamos el camino de decisión registrado, con dueño y criterio, antes de dimensionar cualquier iniciativa agencial.
Fuentes
- vFunction. “2025 Architecture in Software Development Report: Rethinking the Role of Architecture”. 2025. Investigación independiente encargada por vFunction, con 629 líderes y profesionales de tecnología (315 en Estados Unidos, 314 en el Reino Unido).
- McKinsey & Company. “Tech debt: Reclaiming tech equity”. Octubre de 2020. Levantamiento de julio de 2020 con 50 CIOs de empresas de servicios financieros y tecnología con ingresos superiores a US$ 1.000 millones. Citado aquí por el umbral de decisión y por la recomendación contra el big bang, que siguen siendo referencia en la práctica.
- Model Context Protocol. “Specification”. Documentación oficial del protocolo, 2026.
- Gartner. “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027”. Junio de 2025.
- Google Cloud. DORA, programa de investigación DevOps Research and Assessment.