Un sistema legacy no es valioso por ser antiguo. Tampoco es prescindible porque su tecnología haya envejecido. Si sigue interviniendo en facturación, inventario, precios, logística o cualquier proceso esencial, contiene decisiones que la empresa necesita ejecutar cada día.
Parte de ese conocimiento está documentado. Otra parte vive en validaciones, procesos batch, integraciones, datos, excepciones introducidas después de incidentes o incluso procedimientos manuales que los usuarios han incorporado con el tiempo.
Por eso una modernización no debería empezar suponiendo que el código existente es simplemente deuda que hay que eliminar. Primero hay que descubrir qué conocimiento sigue siendo válido, dónde se aplica y cómo comprobaremos que la nueva solución lo conserva o lo modifica deliberadamente.
Una regla no es sólo una condición en el código
Una regla de negocio define cómo debe comportarse la empresa ante una determinada situación. El código es sólo una de las formas en las que puede estar implementada.
Podemos encontrar una regla aparentemente sencilla como: "un pedido confirmado reserva existencias".
Pero su comportamiento real puede depender de la prioridad del cliente, la unidad de medida, los lotes disponibles, procesos posteriores, integraciones que responden con retraso o procedimientos manuales utilizados cuando dos sistemas discrepan.
Copiar el método que realiza la reserva no significa haber recuperado la regla.
El comportamiento puede surgir de la combinación de código, datos, secuencia temporal, dependencias y operación humana.
La documentación ayuda a entender la intención y el sistema en producción muestra lo que realmente sucede. Ninguna de las dos fuentes debe considerarse infalible: la documentación puede estar desactualizada y el comportamiento existente puede contener errores históricos.
Descubrir exige contrastar fuentes
Leer el repositorio es necesario, pero rara vez suficiente.
Las prácticas contrastadas en proyectos de modernización recomiendan combinar diferentes fuentes de información: código, configuración, datos reales, logs, integraciones, pruebas, incidentes conocidos y conocimiento de las personas que trabajan con el sistema.
La propia interfaz puede revelar comportamiento relevante. Si una pantalla impide realizar una acción bajo determinadas condiciones, puede estar reflejando una regla de negocio, pero también una limitación histórica de la aplicación.
Lo importante es no aceptar una única visión del sistema como si fuese toda la verdad.
Cuando distintas fuentes coinciden, aumenta nuestra confianza. Cuando se contradicen, aparece una decisión que debemos investigar.
Esas contradicciones son especialmente valiosas durante una modernización porque convierten supuestos ocultos en decisiones explícitas antes de implementarlos de nuevo.
Conservar comportamiento no significa copiarlo todo
Descubrir cómo funciona el sistema actual no implica convertirlo en una especificación incuestionable.
Un legacy también acumula restricciones que han dejado de tener sentido, duplicidades, soluciones provisionales y errores que terminaron considerándose comportamiento normal.
Por eso conviene clasificar cada regla relevante antes de trasladarla:
- Conservar, porque continúa representando una necesidad real.
- Corregir, porque la intención es válida pero su implementación contiene un problema.
- Reformular, porque seguimos necesitando el resultado pero no la solución histórica.
- Retirar, porque el proceso que la justificaba ya no existe.
- Investigar, porque todavía no tenemos información suficiente.
Que "el sistema siempre lo haya hecho así" explica su historia, pero no demuestra que deba seguir haciéndolo.
También debemos tener cuidado con los datos históricos. Una regla actual puede no haber existido hace diez años o haber funcionado de otra forma. Forzar toda la información histórica a cumplir las reglas presentes puede hacer que perdamos el contexto necesario para interpretarla.
Modernizar no significa reescribir la historia para que encaje en el modelo actual.
Convertir conocimiento en algo verificable
El resultado del descubrimiento no debería ser únicamente documentación.
Las reglas importantes deben convertirse en elementos que podamos comprobar: ejemplos de entrada y salida, casos límite, tablas de decisión, contratos, reglas de integridad o pruebas automatizadas.
Las pruebas de caracterización resultan especialmente útiles porque permiten registrar qué hace actualmente el sistema en determinados escenarios.
No certifican que ese comportamiento sea correcto. Sirven para detectar cuándo cambia. Después corresponde al equipo y al negocio decidir si la diferencia representa una regresión o una corrección intencionada.
Tampoco necesitamos probar cada detalle interno.
En sistemas muy acoplados suele ser más efectivo empezar por límites observables que representen comportamiento relevante para el negocio: una operación, una API, un proceso batch, un informe, un flujo de usuario o una transformación de datos.
La profundidad de estas garantías debe ser proporcional al riesgo. Una regla crítica que se ejecuta miles de veces cada día necesita un nivel de protección distinto de una excepción poco frecuente que requiere intervención humana.
Modernizar por capacidades
Intentar descubrir absolutamente todo antes de modificar una sola línea puede paralizar una modernización.
Hacer lo contrario, reescribir primero y descubrir después, desplaza la incertidumbre hacia producción.
Una estrategia más equilibrada consiste en trabajar por capacidades o flujos acotados. Para cada uno podemos descubrir el comportamiento relevante, establecer cómo observarlo, implementar la nueva solución y comparar resultados antes de ampliar el alcance.
Durante esta transición pueden convivir temporalmente componentes antiguos y nuevos mediante adaptadores, sincronizaciones o mecanismos de comparación.
Esta arquitectura transitoria tiene un coste, pero puede crear algo especialmente valioso: una forma segura de avanzar, observar y corregir antes de retirar definitivamente el sistema anterior.
Patterns of Legacy Displacement
Este enfoque está muy alineado con el trabajo de Ian Cartwright, Rob Horn y James Lewis en Patterns of Legacy Displacement.
Su catálogo de patrones aborda precisamente cómo sustituir progresivamente sistemas legacy sin convertir la modernización en un único cambio de alto riesgo. Analiza cómo desplazar capacidades, crear puntos de separación y utilizar arquitectura transitoria para permitir que el sistema antiguo y el nuevo convivan durante la transición.
Es una lectura que recomendamos especialmente porque no se centra únicamente en cómo debería ser la arquitectura final. También estudia cómo construir un camino seguro para llegar hasta ella.
Esa distinción es fundamental.
Una modernización no debería diseñar únicamente el destino. También debe diseñar la transición.
Conclusión
Modernizar no consiste en preservar código antiguo, sino en conservar el conocimiento que el negocio todavía necesita mientras decidimos conscientemente qué mantener, qué corregir y qué dejar atrás.
Para conseguirlo hay que descubrir el comportamiento desde distintas fuentes, convertir las contradicciones en decisiones y trasladar las reglas importantes a contratos y pruebas que podamos verificar.
Si no hacemos este trabajo, podemos terminar con software técnicamente más moderno que conoce menos del negocio que el sistema al que sustituye.
Pero copiar todo sin cuestionarlo tampoco es modernizar. Puede significar trasladar al nuevo sistema años de decisiones caducadas y limitaciones históricas.
La clave está en entender antes de sustituir y decidir antes de conservar.
Si necesitas trasladar este conocimiento a una transición concreta, consulta nuestro enfoque de modernización de sistemas existentes. Cuando las reglas, dependencias y decisiones pendientes todavía no permiten defender el alcance, un estudio técnico previo a la modernización ayuda a hacer explícita esa incertidumbre.
