Software antiguo. Riesgos crecientes.

Proteger el comportamiento de negocio en lugar de trasladar a ciegas el código heredado

En los sistemas heredados, el código a menudo solo explica una parte del proceso. Las exportaciones a hojas de cálculo, las correcciones manuales de datos y las tareas programadas pueden haber asumido funciones imprescindibles. Registramos estas vías secundarias y elaboramos un catálogo de casos característicos: casos normales, excepciones históricas, valores límite y errores conocidos. Una ejecución comparativa entre el sistema antiguo y el nuevo pone de manifiesto las diferencias, pero todavía no determina qué resultado es correcto desde el punto de vista de negocio.

El área de negocio evalúa las diferencias junto con el equipo de desarrollo. El redondeo, las zonas horarias, el orden de clasificación o las reglas de precios históricas pueden generar desviaciones aparentemente pequeñas con un gran efecto. Los cambios de comportamiento deseados se separan de las regresiones no intencionadas. Solo así se obtiene una base de aceptación adecuada. Los casos documentados sirven después como red de seguridad permanente para futuras transformaciones y conservan un conocimiento que hasta ahora solo poseen algunas personas.

Planificar la gestión de datos en la operación en paralelo y la conmutación

Mientras los componentes antiguos y nuevos trabajen juntos, la responsabilidad de los accesos de escritura no puede quedar sin definir. Determinamos un sistema de referencia para cada ámbito de datos y planificamos el traspaso de esa responsabilidad. Dos aplicaciones que escriben sin coordinación pueden generar estados contradictorios, aunque cada una funcione correctamente por separado. Por eso, la arquitectura intermedia necesita interfaces propias, comprobaciones de coherencia y una vida útil limitada.

Un plan de migración comprende la carga inicial, los cambios intermedios y la comprobación de coherencia final. Verificamos el número de registros, las sumas de negocio, las relaciones y casos individuales representativos. Antes de la conmutación se definen los criterios de interrupción, quién tiene autoridad para decidir y las pausas de escritura admisibles. Una vuelta atrás solo es realista si los datos generados posteriormente pueden volver a procesarse. Cuando esto no es posible, el momento y las consecuencias de este límite se comunican antes de la aprobación.

Desacoplamiento técnico y cierre de la sustitución

Una nueva interfaz de usuario sobre una arquitectura antigua sin modificar no elimina automáticamente sus limitaciones. Analizamos las tablas compartidas, los formatos de archivo implícitos, los accesos directos a la base de datos y las bibliotecas que vinculan varias aplicaciones al mismo tiempo. Los adaptadores introducidos de forma gradual pueden absorber los cambios. Sin embargo, son componentes transitorios con mantenimiento propio y no deberían convertirse, sin que nadie lo note, en un segundo entorno de sistemas permanente.

Por eso, cada función sustituida conlleva también una tarea de retirada. Se comprueba si las tareas programadas, las cuentas de usuario, las interfaces, la infraestructura y las licencias antiguas siguen en uso. Las consultas de información histórica pueden requerir un acceso de solo lectura o una exportación documentada. La modernización de esta etapa solo se considera concluida cuando se han resuelto las dependencias, se ha actualizado la documentación de operación y se han traspasado las responsabilidades. Esto evita que los costes del sistema antiguo y del nuevo se sumen de forma permanente.