Modernizar un Sistema de Construcción que No Puede Apagar

El sistema que más quiere reemplazar suele ser el que no puede detener. Emite las facturas, guarda quince años de historia de obras, y las dos personas que lo entienden están ocupadas. Esa restricción no es un obstáculo para el plan de modernización — es el plan. Una vez que acepta que el sistema viejo sigue corriendo mientras llega el nuevo, casi todas las demás decisiones se desprenden, empezando por el hecho de que no hay fecha de corte.

Resumen rápido

• Un sistema que factura es estructural para la caja. Una fecha de corte es una apuesta a que un día específico salga perfecto.
• La edad no es el problema. No poder cambiar el sistema con seguridad, o perder a quien puede hacerlo, sí lo es.
• La primera tajada debería ser de solo lectura, para que el equipo tenga un despliegue real sin arriesgar una ruta de escritura.
• La corrección se demuestra con paridad: los dos sistemas, las mismas entradas, comparados durante un ciclo completo del negocio.
• El comportamiento del sistema viejo es la especificación, y hay que capturarlo como pruebas antes de reescribirlo.

Esta es la otra mitad de la pregunta de qué construyen las empresas de construcción cuando su plataforma se queda corta. A veces el hueco es un sistema que nunca tuvo. Más seguido es uno que ya tiene, que funciona, y que nadie se atreve a tocar.

¿Por Qué Falla una Reescritura con Fecha de Corte?

Porque lo que se está reemplazando está pegado al movimiento de la plata.

Una administración de obra tiene un ritmo: se registra el avance, se produce un acta, sale una factura, entra la caja. Un sistema en esa cadena no puede estar caído el día en que corre el ciclo, y un reemplazo de golpe concentra todo su riesgo exactamente en uno de esos días. Si algo sale mal, las opciones son revertir una migración que ya escribió datos nuevos, o facturar tarde.

Hay una segunda falla que aparece antes y es menos dramática. Una reescritura es un proyecto largo sin entregable hasta el final, y las empresas de construcción rara vez tienen un año sin interrupciones. Las prioridades se mueven, un proyecto se tuerce, el presupuesto se necesita en otro lado — y la reescritura se abandona al ochenta por ciento, lo que no produce absolutamente nada. El enfoque incremental falla mejor: parar a mitad de camino deja igual las piezas terminadas corriendo en producción.

El patrón alternativo tiene nombre. La descripción de Martin Fowler de la aplicación estranguladora es su formulación más clara: la funcionalidad nueva crece alrededor de los bordes del sistema viejo, interceptando lo que puede, hasta que el viejo hace tan poco que se puede retirar en silencio.

¿Qué Le Cuesta de Verdad un Sistema Viejo?

No lo que la mayoría supone, y por eso el diagnóstico importa más que la edad.

La evidencia pública más clara sobre esto viene del gobierno y no de la construcción. Una revisión de la GAO de 2019 sobre sistemas legacy federales miró los diez sistemas más críticos identificados en diez agencias y los encontró con edades de entre 8 y 51 años. El hallazgo que vale la pena tomar prestado no fueron las edades. Fue que tres de las diez agencias no tenían ningún plan de modernización documentado, y solo dos tenían planes con hitos, descripción del trabajo y un plan de disposición del sistema viejo.

Ese es el patrón real. El costo de un sistema viejo rara vez es la tecnología en sí. Es:

• Latencia de cambio. Una modificación que debería tomar un día toma tres semanas porque nadie está seguro de qué va a romper.
• Concentración en una persona. Una o dos personas lo pueden tocar con seguridad, y el riesgo de la empresa es su calendario.
• Rechazo a integrarse. El sistema no puede hablar con nada nuevo, así que cada herramienta nueva genera redigitación a su alrededor.
• Exposición de seguridad. Una versión de runtime o de base de datos que ya no recibe parches es una decisión, la haya tomado alguien o no.

CodeBranch pasó dos años con dos desarrolladores senior en una plataforma de contabilidad y facturación de construcción construida en Perl y PostgreSQL. El trabajo no fue una reescritura — fue mantenimiento y evolución de un sistema del que la empresa dependía, que es el contexto donde esos cuatro costos dejan de ser abstractos y se vuelven ítems de cronograma.

¿Dónde Debería Ir la Primera Costura?

En algo de solo lectura, donde equivocarse salga barato.

La reportería casi siempre es la primera tajada correcta. El sistema nuevo lee los mismos datos, produce la misma salida, y la factura de nadie está en riesgo si sale mal el primer día. Le da al equipo un despliegue real en producción, un usuario real y — sobre todo — una comparación directa contra la salida existente.

Después de la reportería, la secuencia normalmente va: una ruta de escritura autocontenida con pocas dependencias, luego un módulo con integración pesada, y al final el núcleo. El principio de ordenamiento es tomar las piezas donde la costura ya está limpia antes que aquellas donde hay que inventarla.

Qué hace que una costura esté limpia vale la pena nombrarlo, porque los equipos muchas veces cortan en el lugar equivocado:

• La frontera ya existe en los datos, no solo en el código. Otro módulo lee esto por una tabla o una interfaz en vez de meterse en sus entrañas.
• La pieza puede equivocarse sin corromper nada aguas arriba.
• Hay forma de comparar la salida vieja y la nueva sin que un humano lea las dos.

Un módulo que falla esas tres no es lo primero que se mueve, por mucho que al equipo le disguste.

La misma lógica aplica cuando un sistema se hace crecer en vez de reemplazarlo. La plataforma de control presupuestal que CodeBranch construyó para un contratista eléctrico empezó como una idea con un presupuesto modesto y se expandió módulo a módulo, guiada por lo que la operación necesitaba después y no por una hoja de ruta escrita de antemano. Una modernización es ese mismo proceso apuntado a un sistema existente en vez de a uno vacío.

¿Cómo Se Demuestra que la Ruta Nueva Está Bien?

Con paridad, corrida durante un ciclo completo, antes de apagar nada.

La última fila es el costo honesto. Correr dos sistemas en paralelo es más trabajo que correr uno, y la organización paga ese traslape en plata y en atención. Lo que compra es que nadie tenga que estar seguro de antemano — las diferencias salen como datos y no como incidentes.

La paridad hay que medirla sobre un ciclo completo del negocio, no sobre una muestra. En construcción eso significa un período de facturación entero, porque los comportamientos que difieren suelen ser los que solo ocurren a fin de mes: un cálculo de retención, un cobro parcial de avance, una nota crédito contra un período anterior.

¿Qué Pasa con el Conocimiento Dentro del Sistema Viejo?

Se captura como pruebas, o se pierde.

Todo sistema de larga vida contiene decisiones que nadie recuerda haber tomado: una regla de redondeo, un caso especial para un cliente, una excepción que existe por una auditoría de 2014. Nada de eso está en la documentación. Parte tampoco está en la memoria de nadie — está solamente en el código y en las salidas que lleva una década produciendo bien.

El método que funciona es escribir pruebas contra el sistema existente antes de reemplazarlo. Alimentarlo con entradas conocidas, registrar qué hace, y tratar eso como la especificación. Esto invierte el orden habitual: en vez de documentar la intención y construir hacia ella, uno captura el comportamiento y después decide, caso por caso, cuáles fueron intencionales y cuáles son errores alrededor de los cuales el negocio ya se acomodó.

Esa decisión no le corresponde a un desarrollador solo. Una diferencia de redondeo de unos centavos por línea es un defecto para una persona y una convención de facturación de dos décadas para otra, y la única forma de resolverlo es mostrarle la diferencia a alguien que sea dueño del número. CodeBranch saca estas cosas como decisiones explícitas durante el período de paridad en vez de resolverlas en el código, porque cada una es una regla de negocio que se está volviendo a adoptar, no un bug que se está corrigiendo.

¿Cuándo Conviene Dejarlo Quieto?

Cuando nada de lo que el negocio quiere hacer después está bloqueado por él.

Un sistema viejo, poco glamoroso, entendido por alguien que todavía trabaja ahí y que no le estorba a nada, no es deuda técnica. Es un activo ya pagado. Reemplazarlo consume presupuesto y atención que podrían ir a algo que cambie cómo opera la empresa, y el resultado al final es la misma capacidad que ya tenía.

La prueba es hacia adelante y no técnica. ¿Qué está tratando de hacer el negocio en los próximos dos años — agregar una línea de trabajo, abrir una región, conectarse al sistema de un cliente, soportar una cuadrilla de campo que todavía no existe — y este sistema lo impide? Si la respuesta es no, la decisión correcta es mantenerlo parchado y dejarlo quieto.

Cuando la respuesta es sí, la secuencia importa más que la elección de tecnología, que es la misma razón por la que la estructura de códigos de costo va primero en un sistema que se construye en vez de reemplazarse. CodeBranch trata ese ordenamiento como el primer entregable cuando dimensiona software para empresas de construcción — y cuando la respuesta honesta es que el sistema viejo debería quedarse, esa conclusión también está disponible.