Modernizar software heredado sin una reescritura total

Casi toda empresa consolidada tiene uno: un software al que todos detestan en silencio. Es lento, es feo, media plantilla conoce un truco para el fallo que nadie llegó a corregir, y la única persona que lo entendía se marchó en 2019. El instinto siempre es el mismo: quemarlo y construir uno nuevo. Y ese instinto, más a menudo de lo que parece, es justamente como las buenas empresas pierden un año y una pequeña fortuna a cambio de nada.

He visto fracasar la gran reescritura las veces suficientes como para tener un reflejo al respecto. Un fundador me enseña su crujiente sistema de pedidos o su antiquísima herramienta de planificación, suspira y dice alguna versión de «solo necesitamos reemplazarlo todo». Y quizá algún día lo haga. Pero la reescritura completa —arrancar el viejo sistema, construir uno reluciente en paralelo, pulsar un interruptor— es uno de los movimientos más arriesgados de todo el software. Es cara, tarda mucho más de lo prometido y, durante todo ese tiempo, va a ciegas, confiando en que lo nuevo cubra cada caso extraño que lo viejo resolvía en silencio desde hace quince años.

La buena noticia es que la reescritura total casi nunca es la única opción, y rara vez la mejor. Hay una manera más serena de modernizar: gradual, reversible y considerada con el negocio que aún tiene que ganar dinero mientras usted trabaja. Esta es una guía de ese camino: cómo saber qué necesita arreglo de verdad, cómo sustituir las partes dolorosas sin tirar abajo todo el sistema, y cómo reconocer cuándo una reescritura completa es realmente la decisión correcta.

Por qué la reescritura total es tan tentadora y tan peligrosa

La reescritura completa seduce porque promete un lienzo en blanco. Se acabó el desorden heredado, se acabaron los compromisos, una base de código nueva construida como debe ser con herramientas modernas. En una pizarra parece obvio. En realidad, está firmando reconstruir años de lógica de negocio acumulada —buena parte sin documentar, algo que solo vive en la cabeza de gente que ya se fue— mientras el reloj corre y llegan las facturas.

La trampa más profunda es el problema del universo paralelo. Durante los meses o años que cuesta construir el reemplazo, usted tiene dos sistemas: el viejo, que aún debe sostener el negocio, y el nuevo, que todavía no está listo. Cada cambio que el negocio necesita hay que hacerlo dos veces, o el sistema nuevo se queda atrás de la realidad antes incluso de arrancar. Los equipos se queman manteniendo ambos con vida. Y como nadie puede cambiarse hasta que el nuevo sistema lo haga todo, no hay victoria temprana, ni feedback, ni prueba de que funcione: solo una larga y angustiosa espera hasta un único y enorme día de lanzamiento a todo o nada.

Hay aquí una sabiduría conocida del sector, y bien merecida: el segundo sistema, la gran reescritura, tiende a tardar el triple de lo estimado y a llegar con menos funciones que aquello a lo que reemplaza. La estimación no falla por descuido. Falla porque, al principio, nadie alcanza a ver todas las pequeñas cosas que el viejo sistema hace bien sin decir nada.

Qué significa de verdad 'heredado' (no es cuestión de edad)

Lanzamos la palabra heredado como si solo quisiera decir viejo. No es así. Muchísimo software que lleva una década funcionando está perfectamente bien: aburrido, estable, ya pagado, haciendo su trabajo. La edad por sí sola no es razón para tocar nada. El error más caro de todo este campo es modernizar algo que funcionaba en silencio solo porque parecía anticuado.

El software se gana la etiqueta de heredado cuando empieza a estorbarle activamente. Cuando no puede cambiarlo sin riesgo porque nadie lo entiende del todo. Cuando no logra conectarse con las herramientas de las que hoy depende. Cuando una sola persona es la única capaz de mantenerlo con vida. Cuando es tan lento o frágil que su equipo ha levantado todo un folclore de trucos a su alrededor. Esa es la verdadera definición: no el año en que se escribió, sino el coste que le impone hoy y el riesgo que arrastra hacia mañana.

Diagnostique antes de tocar nada

Antes de reescribir una sola línea, necesita un mapa honesto de dónde vive realmente el dolor. La mayoría de las veces, el sistema que todos odian está bien en un 80 %. El problema se concentra en unos pocos puntos concretos —una pantalla lenta, una integración rota, un flujo que obliga a teclear los datos dos veces— y esos pocos puntos generan casi todas las quejas. Encuéntrelos y habrá encontrado todo su proyecto.

La forma de encontrarlos no es primero una auditoría técnica: es una conversación. Siéntese con quienes usan la herramienta a diario y pregúnteles dónde duele. ¿Dónde esperan? ¿Qué vuelven a teclear? ¿Qué evitan porque es doloroso? ¿Dónde guardan una hoja de cálculo privada para sortear el sistema oficial? Esos trucos son oro: cada uno es una radiografía precisa de un problema que merece arreglarse.

• Las pantallas y los pasos de los que más se queja la gente, no en teoría, sino en su trabajo diario real.
• Cada punto donde los datos se teclean dos veces porque dos sistemas no se hablan entre sí.
• Las integraciones que se rompieron, o que nunca existieron, y obligan a copiar y pegar a mano entre herramientas.
• Todo lo que solo una persona sabe operar o reparar: sus puntos únicos de fallo.
• Las partes que están realmente bien, para protegerlas y dejarlas en paz.
• Lo que el negocio necesitará el año que viene y a lo que el sistema actual sencillamente no puede crecer.

Cuando hace esto con honestidad, el proyecto suele encogerse. El dueño que entró diciendo «reemplazadlo todo» sale dándose cuenta de que necesita arreglar tres cosas. Eso no es una decepción: es un alivio. Tres cosas reparables son un proyecto que puede terminar este trimestre. Un reemplazo completo es un año que quizá no sobreviva.

El enfoque strangler: reemplácelo pieza a pieza

Hay un patrón para hacer esto con seguridad, y tiene un nombre algo lúgubre pero memorable: el enfoque strangler, por la higuera estranguladora, una enredadera que crece alrededor de un árbol y se va apropiando de su estructura hasta que, al final, el nuevo crecimiento se sostiene solo y el viejo tronco ha desaparecido. Aplicada al software, la idea es bellamente práctica: no reemplaza el viejo sistema en un único intercambio heroico. Hace crecer el nuevo a su alrededor, pieza a pieza, hasta que no queda nada del viejo que alguien necesite.

En la práctica funciona así. Elige una pieza dolorosa, digamos el módulo de facturación que todos odian. Construye un reemplazo moderno para solo esa pieza. Encamina la facturación al nuevo módulo mientras todo lo demás sigue funcionando en el viejo sistema, intacto. Lo observa un tiempo. Cuando es sólido, esa parte del viejo sistema se apaga y pasa a la siguiente pieza. El viejo sistema se encoge poco a poco, como una vela, en lugar de venirse abajo de golpe.

Lo que hace esto mucho más seguro que una reescritura es que cada paso es pequeño, en vivo y reversible. Nunca va a ciegas. Cada pieza nueva entra en uso real con rapidez, así que descubre pronto si de verdad funciona. Si algo sale mal, solo ha arriesgado un módulo, no todo el negocio, y normalmente puede volver al camino antiguo mientras lo arregla. Cosecha victorias por el camino en lugar de un único lanzamiento aterrador al final. Y el negocio sigue funcionando, con normalidad, todo el tiempo.

Cómo es realmente el ritmo

1. 1
   Elija la pieza más dolorosa y más autónoma

   Quiere mucho dolor y bordes limpios: un módulo que duela bastante y que no tenga los dedos metidos en todo lo demás. Ese es su primer objetivo.
2. 2
   Coloque una capa fina delante del viejo sistema

   Una pequeña capa de enrutamiento decide qué peticiones van al viejo sistema y cuáles a la nueva pieza. Esa es la costura que hace posible todo lo demás.
3. 3
   Construya y lance solo esa única pieza

   Reemplace un módulo, póngalo en manos reales y encamine hacia él solo esa porción del trabajo. Semanas, no años, y el resto del sistema nunca se movió.
4. 4
   Estabilice y luego pase a la siguiente pieza

   Una vez que el nuevo módulo es de fiar, la parte equivalente del viejo sistema queda en reposo. Repita con la siguiente pieza dolorosa, aprendiendo sobre la marcha.
5. 5
   Retire el viejo sistema cuando esté vacío

   Con el tiempo, el sistema heredado no hace nada de lo que nadie dependa. Solo entonces lo apaga, en silencio, sin dramas, porque todo lo importante ya se mudó.

Fíjese en lo que distingue esto de la reescritura: no hay un único día de lanzamiento que temer. No hay un universo paralelo que mantener. El sistema nuevo está en producción desde la tercera semana, ganándose el sustento y enseñándole cosas, en lugar de esperar en un laboratorio un lanzamiento que no deja de aplazarse.

A veces ni siquiera hace falta reemplazarlo

Antes de reemplazar nada, conviene preguntarse si el viejo sistema necesita reemplazo o solo dejar de ser una isla. Un número sorprendente de problemas de «necesitamos un sistema nuevo» son en realidad problemas de «nuestros sistemas no se hablan». El viejo software hace bien su trabajo; solo está en un silo, obligando a la gente a trasladar datos a mano de un lado a otro.

En esos casos, el arreglo más barato y rápido no es un sistema nuevo. Es un puente. Envuelve el viejo software con una conexión —una integración que le permite intercambiar datos automáticamente con sus otras herramientas— y una capa moderna encima para las partes que la gente realmente toca. El motor anticuado sigue ronroneando debajo; el equipo obtiene una superficie limpia y el fin del copiar y pegar. No es glamuroso, pero a menudo es el mayor retorno por euro de todo el esfuerzo.

Cuándo una reescritura completa es de verdad la decisión correcta

He dedicado toda esta guía a quitarle de la cabeza la gran reescritura, así que seamos justos: a veces es de verdad la respuesta. Hay cimientos tan podridos que ningún parche, puente o reemplazo pieza a pieza los salva, y fingir lo contrario solo retrasa lo inevitable mientras gasta dinero apuntalando un cadáver.

Las señales honestas son concretas. La tecnología sobre la que se construyó el sistema está muerta o agonizando: sin soporte, sin actualizaciones de seguridad, sin nadie que pueda trabajar en ella. El negocio ha cambiado tan a fondo que el viejo modelo ya no se corresponde en absoluto con la realidad. O el sistema está tan enredado que hasta los cambios pequeños rompen rutinariamente cosas en lugares sin relación, lo que suele significar que no hay costuras limpias para aplicar un enfoque strangler de entrada. Cuando dos o tres de esas cosas son ciertas a la vez, el trabajo gradual deja de ser la opción más segura.

Y aquí está la recompensa silenciosa de hacer primero el trabajo gradual, aunque al final acabe reconstruyendo: para cuando llegue ahí, entenderá el sistema mucho mejor que al principio. Cada módulo que reemplazó le enseñó algo que los autores originales nunca dejaron por escrito. Una reescritura guiada por ese conocimiento es un animal completamente distinto, mucho más seguro, que la que se lanza con el optimismo del primer día.

La parte que nadie menciona: es sobre todo cuestión de personas

Aquí va algo que las guías técnicas se saltan. La parte más difícil de modernizar software antiguo no suele ser el código: son las personas que llevan años adaptándose a él. Conocen sus manías. Tienen memoria muscular para sus atajos raros. Un módulo nuevo, objetivamente mejor, puede sentirse peor durante las dos primeras semanas, sencillamente por ser desconocido. Si ignora eso, hasta una migración técnica perfecta puede fracasar.

El enfoque gradual también ayuda aquí, casi por casualidad. Como el cambio llega en pequeñas piezas, la gente lo asimila poco a poco en lugar de tener que reaprenderlo todo un único lunes por la mañana. Involucre pronto a los usuarios diarios. Deje que den forma al reemplazo antes de que esté terminado. El equipo que ayudó a diseñar la nueva pantalla de facturación la defenderá; el equipo al que se la dejaron caer encima la rechazará, aunque sea idéntica. La modernización es un proyecto de gestión del cambio disfrazado de software.

Preguntas frecuentes