El pedido llega casi siempre con las mismas palabras: «esto ya no da para más, hay que hacerlo de nuevo». Y suele ser cierto que ya no da para más. Lo que casi nunca es cierto es que haya que hacerlo de nuevo entero, todo junto, y menos cuando ese sistema es el que factura, el que despacha o el que liquida sueldos.
La reescritura completa tiene un problema que no es técnico sino de plazos. Mientras el equipo nuevo construye el reemplazo, el sistema viejo sigue vivo y sigue cambiando: entra una resolución nueva, un cliente grande pide un formato distinto, se agrega un impuesto. El proyecto nuevo tiene que alcanzar a un blanco que se mueve. Por eso tantas reescrituras terminan a mitad de camino, con dos sistemas funcionando y nadie dispuesto a apagar ninguno.
Lo primero no es programar: es entender qué se usa
Antes de tocar una línea conviene saber qué partes del sistema están vivas de verdad. En sistemas de diez o quince años siempre hay funcionalidad muerta: pantallas que nadie abre desde 2019, reportes que se generan todas las noches y nadie descarga, integraciones con proveedores que ya no existen.
Eso se mide, no se pregunta. Con logs de acceso, con consultas sobre las tablas de auditoría, con un contador puesto en los endpoints durante un par de semanas. El resultado sorprende siempre: es habitual que entre el 30 y el 50 % de las pantallas no tenga uso real. Todo eso no se migra. Se documenta, se avisa y se deja morir.
La red de contención: tests sobre el sistema viejo
El miedo razonable de cualquier gerente es que al tocar el sistema se rompa algo que hoy funciona. La respuesta a ese miedo no es prometer cuidado, es construir una red antes de subirse.
Lo que hacemos son tests de caracterización: en lugar de escribir pruebas sobre lo que el sistema debería hacer, escribimos pruebas que capturan lo que el sistema hace hoy, incluidos los comportamientos raros. Si el cálculo de una comisión redondea mal desde hace ocho años, ese redondeo queda registrado en un test. No porque esté bien, sino porque medio negocio ya está acomodado a ese número y cambiarlo sin avisar sería el verdadero error.
Con esa red puesta, cualquier cambio posterior avisa en cinco minutos si alteró algo. Sin esa red, el aviso llega tres semanas después por teléfono y de mal modo.
Cortar por partes: el sistema nuevo crece alrededor del viejo
La técnica se conoce como estrangulamiento y la idea es simple. Se pone una capa adelante —un proxy, un gateway, a veces el mismo servidor web— que recibe todo el tráfico y decide, ruta por ruta, si esa consulta la atiende el sistema viejo o el nuevo. Al principio atiende todo el viejo. Después, un módulo por vez, se van desviando pedidos al nuevo.
Esto cambia la naturaleza del proyecto. Deja de ser una apuesta grande con una fecha de encendido y pasa a ser una serie de movimientos chicos y reversibles. Si un módulo nuevo se porta mal, se vuelve a apuntar al viejo con un cambio de configuración, no con un rollback de madrugada.
El orden por el que se corta no es caprichoso. Nosotros empezamos por lo que cumple estas tres condiciones a la vez: tiene bordes claros, se toca poco con el resto del sistema y le duele a alguien todos los días. Ese módulo da la primera victoria visible rápido, que es lo que sostiene el proyecto adentro de la empresa cuando llega el tercer mes y la novedad se gastó.
Los datos son la parte difícil
Mover código es relativamente barato. Mover datos con el sistema andando es donde se rompen los proyectos. Durante la transición hay un período en que las dos versiones necesitan la misma información y ninguna puede quedarse atrás.
Hay varias salidas y la elección depende del caso. La más conservadora es que el sistema nuevo lea y escriba sobre la misma base que el viejo, sin migrar nada, hasta que el último módulo esté movido. Es menos elegante y es mucho más segura: no hay sincronización que pueda fallar porque hay una sola fuente de verdad. La migración del modelo de datos se hace después, cuando ya no hay dos sistemas compitiendo.
Cómo se ve un mes de esto
Un mes típico tiene tres o cuatro entregas a producción, no una. Cada una mueve una porción chica y cada una se puede deshacer. Antes de cada corte hay una semana de convivencia: el módulo nuevo procesa en paralelo sin efecto real y se comparan las dos salidas. Si durante siete días dan lo mismo, se enciende. Si difieren, la diferencia se estudia antes de tocar nada.
El reporte que recibe el cliente no es «avanzamos un 40 %», que no significa nada. Es «facturación electrónica ya corre en el sistema nuevo desde el martes, y estas son las dos diferencias que encontramos en la semana de paralelo y cómo las resolvimos».
Cuándo sí conviene reescribir de cero
Para ser justos: hay casos donde el reemplazo total es la decisión correcta. Cuando la plataforma base ya no tiene soporte de seguridad y no hay camino de actualización. Cuando el sistema es chico de verdad —dos o tres meses de trabajo— y el costo de la red de contención se acerca al de rehacerlo. Cuando el negocio cambió tanto que el modelo de datos viejo ya no representa lo que la empresa hace.
Fuera de esos casos, modernizar por partes tarda parecido, cuesta parecido y no te obliga a apostar la operación a que una fecha se cumpla.
Qué preguntar antes de contratar
Si estás evaluando proveedores para un proyecto así, tres preguntas separan bastante rápido:
- ¿Cómo van a saber que no rompieron nada? Si la respuesta no incluye pruebas automáticas sobre el comportamiento actual, la respuesta es que no van a saber.
- ¿Cuál es la primera entrega a producción y en qué semana? Si la primera entrega real es al final, es una reescritura disfrazada.
- ¿Qué pasa si un módulo nuevo falla un martes a las 10? Si no hay una forma de volver atrás en minutos, el riesgo lo estás asumiendo vos.
En Zentavip trabajamos así porque es la única forma que conocemos de modernizar sin pedirle a un cliente que confíe. La confianza se construye con entregas chicas que funcionan, no con un cronograma prolijo.