Nos llega, con cierta regularidad, un tipo de consulta que reconozco de inmediato: “Tenemos un sistema que llevamos años usando, el proveedor que lo construyó ya no existe (o no responde), nadie en nuestro equipo entiende bien cómo funciona por dentro, y últimamente está fallando más seguido. ¿Pueden hacerse cargo?”
La respuesta corta es sí. Pero la pregunta que viene detrás —¿qué significa hacerse cargo?— merece una respuesta más larga y honesta. Eso es lo que escribo acá.
El software heredado no es un problema raro
Cualquier empresa que lleve más de cinco años operando con sistemas propios tiene alguna versión de este problema. Un sistema de gestión construido por un freelancer que ya no trabaja ahí. Un ERP encargado a una empresa que cerró. Un módulo interno que “nadie sabe exactamente qué hace, pero si se cae todo se para”. Una plataforma que el equipo técnico de turno construyó con las mejores intenciones hace ocho años y que hoy es una caja negra que todos temen tocar.
Lo llamo software heredado, pero no en el sentido de “viejo y malo”. Lo heredado es simplemente aquello que recibiste sin documentación completa, sin traspaso formal, sin el contexto de las decisiones que se tomaron cuando se construyó. Puede ser moderno en tecnología y aun así estar a la deriva.
El problema no es el software en sí. El problema es la falta de control. Y eso tiene solución.
El error más caro: el rewrite reflejo
Cuando una empresa llega a este punto, la primera reacción casi siempre es la misma: “Hagamos todo de nuevo desde cero, bien hecho esta vez.” Lo entiendo. Es una respuesta emocional comprensible. El sistema actual genera frustración, y la idea de borrón y cuenta nueva suena liberadora.
Pero es casi siempre un error.
Joel Spolsky, uno de los fundadores de Stack Overflow, llamó a esto “el error único más grave que puede cometer una empresa de software”. La reescritura completa es cara —puede costar entre 2x y 5x lo que costó el original— y es extremadamente riesgosa. El sistema que está funcionando, aunque mal, tiene años de lógica de negocio acumulada, casos borde resueltos, integraciones que nadie documentó pero que alguien conectó cuando era necesario. Reescribir todo implica perder esa historia y volver a aprenderla, esta vez pagándola dos veces.
Lo que hacemos nosotros no es eso.
La toma de control técnica: cuatro fases
Cuando asumimos el control de un sistema heredado, seguimos un proceso en cuatro fases. No es lineal de forma rígida —a veces las fases se superponen— pero el orden importa. Empezar por la fase equivocada genera más daño que no empezar.
Fase 1: Auditoría
Antes de tocar una sola línea de código, necesitamos entender qué tenemos. En la auditoría revisamos:
- Arquitectura general: qué tecnologías, qué versiones, cómo se comunican los componentes.
- Estado del código: calidad, deuda técnica visible, patrones que el sistema usa (o ignora).
- Dependencias: librerías, APIs externas, servicios de terceros. Cuántas están desactualizadas. Cuáles ya no tienen soporte.
- Base de datos: estructura, integridad, volumen, índices, datos huérfanos.
- Infraestructura: dónde corre, cómo se despliega, qué monitoreo existe (si es que hay alguno).
- Puntos de falla conocidos: qué se ha caído antes, qué errores reporta el equipo con más frecuencia.
La auditoría toma entre una y tres semanas dependiendo del tamaño del sistema. Al final entregamos un informe claro: qué está bien, qué es frágil, qué representa riesgo inmediato y qué puede esperar.
La mayoría de los equipos que reciben ese informe por primera vez se sorprenden. No tanto por lo malo que encuentran, sino porque finalmente tienen un mapa de algo que antes era niebla.
Fase 2: Estabilización
Con el mapa en mano, la prioridad es estabilizar. Esto significa resolver los riesgos inmediatos antes de pensar en mejorar nada:
- Actualizar dependencias críticas con vulnerabilidades conocidas.
- Resolver los errores que están causando caídas o pérdida de datos.
- Establecer monitoreo básico: alertas cuando algo falla, no enterarse por un usuario molesto.
- Hacer un backup verificable del estado actual (suena obvio, pero en sistemas heredados es frecuente que el backup exista pero no se haya probado nunca).
La estabilización no agrega funciones nuevas ni mejora la experiencia. Solo pone el sistema en un estado donde se puede operar con más confianza y donde los cambios futuros no van a colapsar algo que ya estaba frágil.
Hay una razón para hacer esto primero: si empiezas a agregar funcionalidades sobre un sistema inestable, cada avance es dos pasos adelante y uno atrás. La deuda técnica actúa como arena movediza.
Fase 3: Documentación y mapa de dependencias
Después de estabilizar, documentamos lo que encontramos. Esto incluye:
- Diagramas de arquitectura actualizados.
- Descripción de los flujos de negocio principales que el sistema soporta.
- Mapa de integraciones: qué se conecta con qué, por qué y bajo qué condiciones.
- Registro de las decisiones de diseño que pudimos reconstruir.
Este trabajo a veces parece “no técnico” y las empresas lo subestiman. Es un error. Sin documentación, el conocimiento queda atrapado en las cabezas de las personas que lo trabajan, y volvemos al mismo problema: el día que esa persona se va, la empresa vuelve al punto de partida. La documentación es lo que transforma el conocimiento tácito en conocimiento institucional.
Fase 4: Modernización progresiva
Recién en esta fase empieza la mejora real. Y la palabra clave es progresiva.
La modernización progresiva significa reemplazar partes del sistema de forma modular, sin apagar lo que funciona. En lugar de la gran reescritura, trabajamos en módulos aislados: primero los más críticos o los más dolorosos, luego los que siguen.
Esto tiene varias ventajas:
- El riesgo está acotado. Si algo sale mal en un módulo, no arrastra al sistema completo.
- El negocio sigue operando durante el proceso. No hay una ventana de downtime de meses mientras se termina la versión nueva.
- Los aprendizajes de los primeros módulos informan los siguientes. Mejoras a medida que avanzas.
En muchos casos, la modernización progresiva termina siendo la opción definitiva. En otros, es un paso intermedio hacia una plataforma completamente nueva, pero construida con tiempo, con aprendizaje y con mucho menos riesgo.
¿Cuándo sí conviene la reescritura?
Hay casos donde la reescritura completa es la decisión correcta. Los criterios que nosotros usamos:
- El costo anual de mantener el sistema (soporte, parches, horas de ingeniería para no romperse) supera o se aproxima al costo de construirlo de nuevo.
- La tecnología base ya no tiene soporte activo y la migración de dependencias sería más costosa que la reescritura.
- El sistema tiene tan poca lógica de negocio válida que hay poco que conservar.
- La arquitectura original es tan rígida que no permite la modernización progresiva sin costos prohibitivos.
Fuera de esos casos, lo que suele verse es que la reescritura se justifica emocionalmente, no técnicamente. Y las empresas que han pasado por una aprenden esto de la manera cara.
Lo que cuesta: auditoría vs. rescate vs. reescritura
Esta tabla muestra rangos orientativos para un sistema mediano (una aplicación web con base de datos, algunas integraciones y entre 5 y 50 usuarios activos). Son valores referenciales de mercado chileno 2026; el costo real depende del estado y complejidad del sistema. Valor UF referencial: ~$39.300 CLP; dólar referencial: ~$950.
| Opción | Rango (UF) | Aprox. CLP | Aprox. USD | Plazo típico |
|---|---|---|---|---|
| Auditoría técnica | 30–80 UF | $1,2M – $3,1M | US$1.300 – 3.300 | 1–3 semanas |
| Auditoría + estabilización | 80–200 UF | $3,1M – $7,9M | US$3.300 – 8.300 | 4–8 semanas |
| Modernización progresiva | 200–800 UF | $7,9M – $31,4M | US$8.300 – 33.000 | 3–12 meses |
| Reescritura completa | 400–2.000+ UF | $15,7M – $78,6M+ | US$16.600 – 83.000+ | 6–18 meses |
La diferencia de costo entre el rescate y la reescritura suele ser entre 2x y 4x. En sistemas más grandes, más. Y el rescate tiene mucho menos riesgo de salir mal.
El rol de la IA en la auditoría
Somos un equipo AI-native y eso cambia cómo hacemos el trabajo en esta fase de forma concreta.
Cuando llegamos a un sistema sin documentación, el análisis manual del código puede tomar semanas. Con herramientas de análisis asistido por IA, podemos generar un mapa de dependencias de todo el sistema, identificar patrones problemáticos y reconstruir la lógica de negocio incrustada en el código en una fracción del tiempo. Lo que antes tomaba 3 semanas de ingeniería senior, hoy puede tomar 4 o 5 días.
Eso tiene dos efectos:
Primero, la auditoría es más barata. La misma profundidad de análisis cuesta menos horas de ingeniería.
Segundo, el informe es más completo. Porque podemos cubrir más superficie de código en el mismo tiempo, aparecen problemas que antes habrían quedado fuera de la auditoría por razones de presupuesto.
El análisis de IA no reemplaza el criterio del ingeniero que entiende el contexto de negocio. Lo que hace es eliminar la parte mecánica del trabajo —leer miles de líneas de código buscando patrones— para que el ingeniero gaste su tiempo en lo que importa: interpretar lo que encontró.
Cuándo nos llaman
No esperamos que lleguen a nosotros en la peor versión del problema. Idealmente, la consultoría informática de rescate empieza cuando el sistema aún funciona pero ya hay señales de alarma.
Las señales que más vemos:
- Nadie en el equipo actual sabe responder con confianza qué pasa cuando falla un componente específico.
- Los cambios, aunque pequeños, demoran semanas en implementarse porque “hay que tener cuidado de no romper nada”.
- Hay partes del sistema que llevan meses sin que nadie las toque, no porque no sean necesarias, sino porque nadie se atreve.
- Hay dependencias de personas específicas que “conocen el sistema”: si esa persona se va, hay un riesgo operacional real.
- El proveedor original desapareció o ya no responde con seriedad.
Si reconoces dos o más de estas situaciones, el problema ya está instalado. La pregunta no es si hay que resolverlo, sino cuándo y cómo.
Lo que hacemos distinto
Cuando asumimos el control de un sistema, no empezamos por proponer que se reescriba todo. Eso sería conveniente para nosotros en términos de facturación, pero no es lo que le conviene al cliente.
Lo que proponemos siempre es partir por entender. Auditoría primero, decisión después. Con el mapa en mano, la decisión entre rescatar, modernizar progresivamente o reescribir se toma con datos, no con intuición.
Y si el sistema es rescatable —que en la mayoría de los casos lo es— la ruta de software a medida progresivo suele ser significativamente más barata y mucho menos riesgosa que empezar de cero.
En varios de nuestros casos el origen fue exactamente este: un sistema heredado que necesitaba un dueño técnico nuevo. La integración de sistemas existentes con nuevas capas, la estabilización y la modernización gradual. No llegamos con una hoja en blanco, llegamos con el sistema tal como estaba y lo hicimos evolucionar.
Ese es el trabajo que más nos gusta. No el que empieza limpio, sino el que requiere entender antes de actuar.
Preguntas frecuentes
¿Qué es una auditoría técnica de software heredado?
Es un diagnóstico profundo del sistema existente: código, arquitectura, dependencias, base de datos y documentación disponible. El objetivo es entender qué hay, qué funciona bien, qué es frágil y qué representa riesgo antes de tocar nada. Al final del proceso tienes un mapa claro del estado real de tu sistema.
¿Siempre conviene reescribir un sistema heredado?
No. La reescritura completa es la opción más cara y más riesgosa. En la mayoría de los casos conviene estabilizar, documentar y modernizar por partes. Solo se justifica reescribir cuando el costo de mantener supera ampliamente el de construir de nuevo, o cuando la plataforma tecnológica base ya no tiene soporte activo.
¿Cuánto demora una toma de control técnica?
Una auditoría inicial toma entre 1 y 3 semanas según el tamaño y complejidad del sistema. La estabilización puede sumar 1 a 2 meses adicionales. La modernización progresiva es un proceso de mediano plazo: entre 6 y 18 meses dependiendo del alcance.
¿Qué pasa si no hay documentación del sistema?
Es lo más común en proyectos heredados. Lo reconstruimos desde el código mismo: análisis estático, entrevistas al equipo operativo y trazabilidad de datos. La documentación que no existe la generamos como parte del proceso de auditoría. Cuando terminamos, la empresa tiene documentación que antes no tenía.
¿Pueden rescatar un sistema construido por otro proveedor?
Sí. Es uno de los servicios que hacemos con más frecuencia. Tomamos el código donde está, hacemos la auditoría y asumimos la continuidad. No exigimos que el sistema cumpla ningún estándar particular ni que esté en ninguna tecnología específica para empezar.
Si tienes un sistema que sientes que está a la deriva, el primer paso no es decidir qué hacer con él. Es entender qué tienes. Contáctanos para una consultoría de diagnóstico sin compromiso: en una o dos semanas te decimos qué encontramos y cuáles son las opciones reales.