Sistemas heredados: cómo decidir entre mantener, corregir o reemplazar

Qué se revisa primero

Antes de proponer cualquier camino se revisan cinco cosas, en este orden:

• El código: si se puede leer, compilar y ejecutar fuera del entorno original, y si tiene pruebas.
• La infraestructura: dónde corre, con qué versiones y quién tiene acceso.
• La documentación que exista: diagramas, manuales, decisiones tomadas.
• Los datos: dónde están, en qué estado y cómo se respaldan.
• Las personas: cuántas conocen el sistema y qué pasa si alguna deja de estar.

El resultado es un informe corto con lo que funciona, lo que está en riesgo y lo que se desconoce. Esa última parte importa tanto como las otras.

Cuándo conviene corregir

Corregir tiene sentido si el sistema cumple su función, el código es entendible y los cambios que se necesitan son acotados. En ese caso el trabajo suele ser ordenar lo que existe: documentar, agregar pruebas a las partes críticas, actualizar dependencias con soporte y mover el sistema a una infraestructura reproducible.

Es la opción de menor riesgo, y casi siempre la primera que se debe descartar con argumentos antes de pasar a reemplazar.

Cuándo conviene reemplazar

Las señales más claras son técnicas y operativas:

• La tecnología base ya no recibe actualizaciones de seguridad.
• No se puede probar un cambio sin arriesgar la operación.
• Cada modificación cuesta más que la anterior y nadie puede estimar el esfuerzo.
• El sistema depende de una sola persona o de un equipo que ya no está.
• No puede conectarse con otros sistemas que la institución necesita.

Cuando se cumplen varias a la vez, seguir manteniéndolo suele costar más que reemplazarlo, aunque el gasto se reparta en pequeñas cuentas que no se ven juntas.

Reemplazar por etapas, sin detener la operación

Reescribir todo y cambiar un día es la forma más riesgosa de reemplazar. La alternativa es hacerlo por funciones:

• Se replica una función del sistema antiguo en una aplicación nueva y mantenible.
• Se migra el uso de esa función, con ambos sistemas funcionando en paralelo durante un período acordado.
• Cuando la función nueva está estable, se retira la antigua y se pasa a la siguiente.

Los datos se migran con un inventario previo: qué se mueve, qué se archiva y qué se descarta. Cada etapa tiene criterios de aceptación escritos, de modo que se puede detener o reorientar el proyecto sin haber perdido lo ya construido.

Qué debe quedar por escrito

Cualquiera sea la decisión, conviene dejar un documento con la arquitectura recomendada, las alternativas descartadas y por qué, los riesgos y dependencias de terceros, el plan por etapas con su plazo y los criterios con que se aceptará cada una. Es lo que permite justificar la decisión, y también retomarla si cambia el equipo.