Tu negocio sigue funcionando. El sistema cambia por debajo.

Lo que se le pide a estos sistemas es nuevo: que un agente pueda averiguar qué contienen y actuar sobre eso, sin una persona en el medio traduciendo.

La mayoría de los sistemas que llevan años corriendo no pueden responder eso, y la razón no es su edad. Es que lo que saben está repartido entre código, stored procedures, jobs programados y convenciones que nadie escribió, la misma razón por la que son difíciles de explicarle a un desarrollador nuevo.

Esa superposición es la parte útil. Una descripción de qué contiene el sistema, dónde están sus límites y qué operaciones son seguras de llamar es la mayor parte del trabajo en los dos casos, lo que significa que no tiene que ser un programa aparte con su propio presupuesto.

Conviene resolverlo antes de fijar el plan de modernización, porque cambia qué significa terminado.

Los modelos leen bien código desconocido, y producen rápido algo que parece equivalente. Esa parte del trabajo se abarató de verdad, y no hay razón para esperar que se encarezca.

La prueba no se abarató. Antes de poder apagar el componente viejo, alguien tiene que establecer que el nuevo se comporta igual, incluidos los casos que nadie escribió, los que existen porque un cliente se quejó una vez y se agregó una regla sin decirlo.

Esa evidencia no se genera. Se construye, a partir del comportamiento del propio sistema: los datos que ya procesó, las excepciones que ya maneja, las salidas que ya produjo y en las que alguien río abajo ya confía.

Un programa que produce código nuevo rápido y evidencia despacio no se volvió más rápido. Movió el riesgo al final, que es el lugar más caro para encontrarlo. La mayor parte de nuestro esfuerzo va a la segunda mitad.