Si tu empresa está evaluando reescribir un sistema heredado, la primera inversión no debería ser programar: debería ser entender qué existe, qué sostiene al negocio y qué riesgos quedarían expuestos durante la transición.
Una auditoría de software legacy permite responder una pregunta concreta: ¿conviene reescribir, modernizar por partes, encapsular o seguir operando con mejoras puntuales? La respuesta no depende solamente de que el código sea viejo. Depende de la calidad de los datos, la criticidad de los procesos, la seguridad, la capacidad de desplegar cambios y el conocimiento que todavía conserva el equipo.
Respuesta corta
Antes de invertir en un rewrite, auditá siete áreas: datos, autenticación y autorización, pagos, despliegue, observabilidad, dependencias y conocimiento operativo. Documentá los flujos críticos, identificá integraciones ocultas y medí qué puede romperse si cambiás una pieza.
Un rewrite puede ser la decisión correcta cuando el sistema impide evolucionar, aumenta el riesgo operativo o consume una parte desproporcionada del tiempo del equipo. Pero también puede convertirse en un proyecto largo y costoso si se subestima la lógica de negocio que no está escrita en ningún documento.
La recomendación práctica es construir primero un mapa técnico y operativo. Con ese mapa, la empresa puede elegir una estrategia gradual y verificable en lugar de apostar todo a una fecha de reemplazo.
1. Datos: el activo más difícil de reemplazar
El código puede reescribirse. Los datos históricos, las relaciones entre tablas y las excepciones acumuladas son mucho más difíciles de reconstruir.
La auditoría debería empezar por identificar:
- Qué bases de datos existen y qué sistemas las leen o escriben.
- Cuáles son las tablas y entidades críticas para la operación.
- Qué campos tienen significado ambiguo, valores nulos o formatos inconsistentes.
- Si hay procesos que dependen de triggers, jobs, procedimientos almacenados o scripts manuales.
- Cómo se generan los identificadores y qué sistemas externos los conocen.
- Qué información debe conservarse, migrarse, anonimizarse o descartarse.
- Qué datos son la fuente principal y cuáles son copias, cachés o reportes derivados.
- Cómo se crean, desactivan y recuperan las cuentas.
- Si existen usuarios compartidos o credenciales embebidas en integraciones.
- Qué roles y permisos están definidos.
- Si los permisos se aplican en la interfaz, en la API, en la base o en más de un lugar.
- Cómo se manejan sesiones, tokens, vencimientos y cierres de sesión.
- Qué acciones requieren aprobación adicional o doble control.
- Cómo se registran los accesos y cambios sensibles.
- Inicio de la operación y validaciones previas.
- Generación de órdenes, comprobantes o referencias.
- Comunicación con proveedores de pago o bancos.
- Confirmaciones, rechazos, reintentos y timeouts.
- Conciliación entre el sistema interno y el proveedor.
- Devoluciones, anulaciones y operaciones pendientes.
- Idempotencia: qué evita que una misma operación se procese dos veces.
- Evidencia disponible para investigar un incidente.
- Dónde vive el código y cómo se versiona.
- Qué pasos son automáticos y cuáles se ejecutan manualmente.
- Cómo se administran los ambientes de desarrollo, prueba y producción.
- Dónde están las variables de configuración y los secretos.
- Cómo se ejecutan las migraciones de base de datos.
- Qué dependencias tiene el build.
- Cómo se hace rollback.
- Qué backups existen y cuándo se verificó una restauración.
- Qué tareas programadas o procesos batch corren fuera de la aplicación.
- Logs estructurados con identificadores de correlación.
- Métricas de errores, latencia, volumen y saturación.
- Alertas con responsables definidos.
- Trazabilidad entre la aplicación, la base y los servicios externos.
- Registro de eventos de negocio, no solo errores técnicos.
- Retención suficiente para investigar incidentes.
- Paneles que el equipo realmente consulte.
- ¿Qué sistemas externos consume la aplicación?
- ¿Qué sistemas consumen a la aplicación?
- ¿Qué contratos de datos existen?
- ¿Qué ocurre si una dependencia está caída o responde lento?
- ¿Hay formatos de archivo o endpoints no documentados?
- ¿Existen integraciones mantenidas por un proveedor que ya no participa?
- ¿Qué certificados, dominios o credenciales requieren renovación?
- Procesos críticos y sus responsables.
- Excepciones frecuentes.
- Tareas manuales y controles compensatorios.
- Decisiones que requieren experiencia del negocio.
- Incidentes históricos y sus soluciones.
- Términos internos que no aparecen en el código.
- [ ] Existe un inventario actualizado de aplicaciones, bases e integraciones.
- [ ] Están identificados los flujos críticos de negocio.
- [ ] Se conoce el origen y el uso de los datos principales.
- [ ] Hay una estrategia preliminar de migración y reconciliación.
- [ ] Los roles y permisos fueron probados más allá de la interfaz.
- [ ] Los pagos y operaciones sensibles tienen estados y reintentos documentados.
- [ ] El despliegue, rollback y recuperación fueron descriptos paso a paso.
- [ ] Se conocen las tareas automáticas y manuales fuera del código.
- [ ] Existen señales mínimas de observabilidad para cada flujo crítico.
- [ ] Las dependencias externas tienen responsables y contratos claros.
- [ ] El conocimiento operativo fue relevado con usuarios y operadores.
- [ ] Se definieron criterios para decidir qué migrar, reemplazar o retirar.
Un error frecuente es asumir que la base de datos refleja todo el dominio. En sistemas heredados, parte de la lógica puede vivir en planillas, integraciones, tareas programadas o instrucciones que solo conoce una persona.
Por ejemplo, una tabla de estados puede contener valores como A, P, C y X, pero su significado real quizás no esté documentado. Antes de migrarla, hay que verificar qué representa cada valor, qué pantallas lo modifican y qué reportes lo interpretan. Cambiarlo por nombres más claros sin entender sus usos puede alterar procesos que parecen independientes.
También conviene definir una estrategia de reconciliación. No alcanza con copiar registros y comprobar que el total coincida. Hay que validar saldos, estados, relaciones, fechas, permisos y casos excepcionales. Una migración confiable necesita pruebas con datos representativos y un mecanismo para detectar diferencias.
2. Autenticación y autorización: quién puede hacer qué
La autenticación responde quién es el usuario. La autorización responde qué puede hacer. En software legacy, ambas responsabilidades suelen estar mezcladas y pueden cambiar según el canal, la sucursal, el rol o el estado de una operación.
Revisá:
Un caso habitual: la pantalla oculta un botón para un usuario sin permisos, pero el endpoint todavía acepta la operación si se invoca directamente. En un rewrite, esa diferencia puede desaparecer o, peor, puede mantenerse sin ser detectada. Por eso los permisos deben probarse en cada frontera del sistema, no solo desde la experiencia visual.
Si el producto integra un proveedor externo de identidad, documentá qué atributos llegan, cómo se mapean los roles y qué ocurre cuando un usuario cambia de puesto. Una integración correcta en el login no garantiza una autorización correcta dentro del sistema.
3. Pagos y operaciones sensibles
Los pagos requieren una revisión específica porque una falla puede producir pérdidas, duplicaciones, reclamos o bloqueos operativos. No hace falta asumir una regulación concreta para tratarlos como procesos de alta criticidad.
El mapa debería incluir:
Un ejemplo práctico: el usuario recibe un timeout después de pagar. Si el sistema reintenta automáticamente sin una clave idempotente, puede generar una segunda solicitud. Antes de un rewrite, hay que saber dónde se guarda el identificador de la operación, qué respuesta se considera definitiva y quién reconcilia los casos ambiguos.
Para cada flujo, documentá una matriz simple:
| Escenario | Estado interno | Respuesta externa | Acción esperada |
| Operación aprobada | Confirmada | Aprobada | Emitir comprobante y registrar auditoría |
| Operación rechazada | Rechazada | Rechazada | Informar y permitir un nuevo intento según corresponda |
| Timeout | Pendiente | Sin respuesta clara | Consultar estado antes de reintentar |
| Duplicado | En revisión | Dos referencias posibles | Bloquear procesamiento automático y conciliar |
| Devolución | Devuelta | Confirmada | Actualizar estado y conservar la trazabilidad |
La meta no es producir una documentación perfecta. Es hacer visibles las decisiones que el nuevo sistema deberá preservar.
4. Despliegue y capacidad de recuperación
Un sistema puede tener una arquitectura razonable y aun así ser difícil de operar si nadie sabe cómo ponerlo en producción o recuperarlo después de un incidente.
Auditá el camino completo desde un cambio hasta su disponibilidad:
Una señal de riesgo es que el despliegue dependa de una persona que recuerda una secuencia de comandos, copia archivos a mano o modifica configuraciones directamente en producción. Esa práctica puede haber sido funcional durante años, pero vuelve difícil estimar el impacto de un cambio.
Antes del rewrite, conviene capturar una línea base: tiempos de despliegue, frecuencia de incidentes, duración de recuperaciones y puntos manuales. No para inventar métricas, sino para tener una referencia concreta al comparar la solución nueva.
5. Observabilidad: saber qué está pasando
Si el sistema falla, ¿cuánto tarda el equipo en detectar el problema y encontrar su causa? La respuesta revela tanto como una revisión del código.
Buscá si existen:
Un log que dice “falló la operación” aporta poco. Un registro con el identificador de la orden, el paso del flujo, el proveedor involucrado y el resultado permite investigar sin adivinar. La observabilidad también debe respetar los controles de acceso y evitar exponer información sensible.
En un rewrite, instrumentar todo al final suele ser caro. Definí desde el inicio qué señales indican que el sistema funciona: pedidos creados, pagos confirmados, mensajes procesados, tiempos de respuesta y errores por integración.
6. Dependencias e integraciones ocultas
El sistema heredado rara vez vive aislado. Puede depender de APIs, archivos, colas, servidores de correo, servicios de identidad, proveedores de pago, procesos contables o herramientas internas.
Armá un inventario con estas preguntas:
Prestá especial atención a las dependencias “temporales” que llevan años funcionando. Un script que exporta un CSV todas las noches puede ser parte esencial de la operación aunque no figure en ningún diagrama.
Antes de reemplazar una integración, probá el comportamiento real: formatos, campos opcionales, errores, límites y reintentos. La documentación del proveedor puede no reflejar todas las particularidades del uso actual.
7. Conocimiento operativo y lógica no escrita
La última área suele ser la más subestimada: el conocimiento de las personas.
Entrevistá a quienes usan, mantienen y operan el sistema. No les preguntes solamente qué pantallas utilizan. Preguntá qué hacen cuando algo sale mal, qué excepciones conocen, qué controles agregan manualmente y qué tareas no aparecen en el procedimiento oficial.
Un equipo puede saber que “antes de cerrar el día hay que ejecutar una consulta y corregir dos estados”. Esa actividad quizás sea una compensación por una limitación del software. Si no se descubre, el rewrite puede eliminar la solución informal sin resolver el problema original.
Documentá:
Checklist de auditoría antes del rewrite
¿Rewrite total o modernización gradual?
Con la auditoría terminada, la decisión suele dividirse en cuatro caminos:
1. Mantener y mejorar: adecuado cuando el sistema es estable y el problema principal está en algunos módulos o procesos.
2. Encapsular: útil cuando se necesita exponer capacidades del sistema mediante APIs sin modificar todavía el núcleo.
3. Reemplazar por partes: permite migrar un flujo crítico, validar la convivencia y reducir el riesgo de un corte total.
4. Reescribir: tiene sentido cuando la arquitectura, el costo operativo o las limitaciones del sistema impiden evolucionar de manera razonable.
La opción más conveniente no siempre es la más moderna. Es la que reduce riesgo y habilita el siguiente paso del negocio con evidencia suficiente.
Para una empresa argentina, además, es importante contemplar la realidad operativa del equipo: disponibilidad de especialistas, continuidad de proveedores, diferencias entre ambientes, integraciones locales y capacidad de sostener dos sistemas durante una transición. Estos factores no determinan por sí solos la estrategia, pero sí afectan su viabilidad.
Próximo paso
Una auditoría útil termina con decisiones accionables: mapa de dependencias, riesgos priorizados, flujos críticos, estrategia de migración y una recomendación técnica conectada con los objetivos del negocio.
Si necesitás ordenar esa evaluación antes de comprometer presupuesto y calendario, podés conocer nuestros servicios, revisar ejemplos de proyectos o contactarnos para conversar sobre el contexto de tu sistema heredado.
