Deuda técnica en sistemas legacy: cómo cuantificarla antes de que te cueste caro

Hay un sistema en tu empresa que nadie quiere tocar. Funciona, más o menos. Cada cambio toma semanas. Solo una persona lo entiende del todo, y reza para que no renuncie. Cuando alguien propone modernizarlo, la respuesta es siempre la misma: “ahora no, está funcionando”.

Ese sistema tiene deuda técnica. Y, como toda deuda, acumula intereses. La diferencia es que estos intereses no aparecen en ningún estado financiero — se pagan en velocidad perdida, en errores recurrentes y en horas de gente cara apagando incendios en lugar de construir.

Este artículo no es sobre tecnología. Es sobre cómo poner un número a ese costo invisible para tomar una decisión de negocio informada.

Qué es realmente la deuda técnica

El término viene de una analogía financiera: tomas un atajo en el desarrollo para entregar más rápido, igual que pides un préstamo para comprar antes. El atajo te da velocidad hoy, pero genera una obligación futura: en algún momento habrá que “pagar” ese atajo con trabajo extra.

No toda la deuda técnica es mala. A veces es una decisión estratégica consciente: lanzas un producto imperfecto para validar el mercado, sabiendo que después refactorizarás. El problema es la deuda técnica no gestionada: la que se acumuló sin decisión, durante años, hasta volver el sistema casi imposible de cambiar.

En los sistemas legacy — Delphi, VB6, COBOL, PowerBuilder, versiones antiguas de .NET o Java sin mantenimiento — la deuda suele ser de este segundo tipo. No la eligió nadie; simplemente se sedimentó.

Cómo cuantificar el costo (sin ser técnico)

No necesitas leer el código para medir la deuda técnica. Necesitas medir su impacto operativo. Cuatro métricas que cualquier directivo puede obtener:

1. Tiempo de cambio (lead time)

¿Cuánto tarda una solicitud simple — agregar un campo a un formulario, cambiar una regla de cálculo — desde que se pide hasta que está en producción? En un sistema sano son días. En uno con deuda alta son semanas o meses. Multiplica esa lentitud por la cantidad de cambios que tu negocio necesita al año y tienes el costo de oportunidad.

2. Tasa de errores en producción

¿Con qué frecuencia un cambio rompe algo que antes funcionaba? Si tu equipo tiene miedo de tocar el sistema porque “siempre se rompe algo”, eso es deuda técnica midiéndose sola. Cada incidente tiene un costo: horas de soporte, operación detenida, confianza del cliente erosionada.

3. Concentración de conocimiento (bus factor)

¿Cuántas personas entienden cada parte crítica del sistema? Si la respuesta es “una”, tienes un riesgo existencial disfrazado de normalidad. El día que esa persona se va de vacaciones, se enferma o renuncia, el costo de la deuda se vuelve catastrófico e inmediato.

4. Costo de mantenimiento vs. inversión nueva

¿Qué porcentaje de tu presupuesto de tecnología se va en mantener lo que ya existe versus construir cosas nuevas? Cuando el mantenimiento supera el 60-70%, tu empresa está corriendo para quedarse en el mismo lugar. La deuda técnica te está comiendo la capacidad de innovar.

La fórmula simple

No necesitas un modelo sofisticado. Una estimación honesta basta para decidir:

Costo anual de la deuda ≈
   (horas/mes apagando incendios × costo hora del equipo × 12)
 + (valor de los cambios que NO se hacen por miedo o lentitud)
 + (riesgo de concentración de conocimiento, como provisión)

Cuando pones números reales, el resultado suele sorprender. Sistemas que “funcionan” están costando, en deuda, varias veces lo que costaría modernizarlos — solo que el costo está repartido y disfrazado de “así es esto”.

Modernizar vs. seguir parchando: cuándo cambia la balanza

No todo sistema legacy debe modernizarse. La decisión depende de dos ejes:

• Criticidad para el negocio: ¿es un sistema central o periférico?
• Velocidad de cambio requerida: ¿necesitas evolucionarlo seguido o casi nunca?

Un sistema periférico y estable puede vivir con su deuda durante años; modernizarlo sería gastar capital sin retorno. Pero un sistema central que necesitas cambiar seguido y que está frenado por la deuda es justo lo contrario: cada mes que esperas, pagas intereses que nunca recuperas.

La pregunta correcta no es “¿el sistema funciona?”. Es “¿este sistema me deja moverme a la velocidad que mi negocio necesita?”.

El rol de la IA en la modernización (y sus límites)

En 2026, la IA cambió la economía de modernizar legacy. Herramientas asistidas por IA pueden leer código antiguo, documentarlo, mapear dependencias y proponer equivalencias en stacks modernos. Eso reduce drásticamente el costo del trabajo más tedioso: entender un sistema que nadie documentó.

Pero hay un límite claro. La IA puede traducir qué hace el código; no puede saber por qué lo hace ni qué reglas de negocio están enterradas en esa lógica. Una modernización dirigida solo por IA reproduce los errores del sistema viejo en un lenguaje nuevo. La IA acelera; el criterio humano y el conocimiento del dominio deciden qué se conserva, qué se corrige y qué se elimina.

Cómo modernizar sin detener la operación

La modernización exitosa rara vez es un “big bang” donde apagas lo viejo y enciendes lo nuevo el mismo día. Ese enfoque es el que llena los titulares de proyectos fracasados. Los patrones que funcionan son incrementales:

• Strangler Fig: construyes lo nuevo alrededor de lo viejo, migrando función por función, hasta que el sistema legacy queda vacío y se apaga sin drama.
• API-first: expones el sistema viejo detrás de APIs modernas, lo que te permite construir lo nuevo encima sin reescribir el núcleo de inmediato.
• Migración por dominios: modernizas primero la parte que más duele (la de mayor deuda y mayor criticidad) y demuestras valor antes de seguir.

Conclusión

La deuda técnica es real, se paga sí o sí, y el hecho de que no aparezca en el balance no la hace menos costosa — la hace más peligrosa, porque no se gestiona lo que no se mide.

Antes de la próxima vez que tu equipo diga “ese sistema mejor no lo tocamos”, haz el ejercicio: mide el tiempo de cambio, la tasa de errores, la concentración de conocimiento y el costo de mantenimiento. Pon un número. Con ese número, la decisión de modernizar deja de ser una intuición técnica y se vuelve lo que siempre debió ser: una decisión de negocio.