Hay una frase que he escuchado en casi todas las empresas a las que he llegado con un producto maduro entre manos: «esto está tan mal que lo mejor es reescribirlo entero».
La he dicho yo también. Con total convicción. Mirando un código que nadie se atrevía a tocar, con dependencias que parecían sostenerse por fe y una documentación que consistía en preguntarle a la única persona que llevaba allí siete años.
Cuando entré como CTO en Enterticket, me encontré justo con ese escenario: un producto legacy que funcionaba —facturaba, tenía clientes reales, sostenía operaciones todos los días— pero que costaba un mundo evolucionar. Y, como era de esperar, en una de las primeras reuniones alguien puso sobre la mesa la opción nuclear: empezar de cero.
Tardé poco en darme cuenta de que esa era, casi siempre, la peor decisión que podíamos tomar.
La trampa del Big Rewrite
El Big Rewrite es la trampa favorita del ego técnico. Y lo digo sin condescendencia, porque he caído en ella.
Es seductora por varios motivos. Es más divertido construir algo nuevo que entender algo viejo. Da la sensación de control: «esta vez lo haremos bien». Y permite no enfrentarse a la parte incómoda de la ingeniería, que es convivir con las decisiones —buenas y malas— que tomaron otros antes que tú.
El problema es que reescribir desde cero un sistema que está en producción es apostar el negocio a una sola carta. Mientras construyes el reemplazo, el mundo no se detiene: el sistema viejo sigue vivo, sigue necesitando parches, y tu competencia sigue enviando funcionalidades nuevas que tú no puedes igualar porque todo tu equipo está ocupado reconstruyendo lo que ya tenías.
Dieciocho meses después —si llegas— estrenas un producto que, en el mejor de los casos, hace lo mismo que el anterior. Cero valor nuevo para el cliente durante todo ese tiempo. Y eso suponiendo que el proyecto termine, cosa que muchas veces no ocurre.
Lo que de verdad pierdes cuando reescribes
Por encima del riesgo de plazos, hay tres cosas que se pierden y que casi nunca aparecen en la estimación inicial.
Las reglas de negocio que viven escondidas en el código. Ese if extraño que parece un error es, casi siempre, la cicatriz de un caso real: un cliente importante, una excepción legal, un bug que costó dinero. Cuando reescribes, esas reglas no están en ningún documento. Están en el código que vas a tirar. Y las redescubres una a una, en producción, normalmente cuando se rompen.
El momentum. Un equipo que pasa más de un año sin entregar valor visible se desgasta. La dirección se impacienta, los comerciales no tienen nada nuevo que contar y la moral del equipo se erosiona. La energía de construir algo nuevo dura tres meses; el rewrite dura mucho más.
El dinero, que no es un detalle. Cada mes de reescritura es coste sin retorno. No estás reduciendo deuda técnica de forma incremental: estás financiando una promesa.
La alternativa: modernización evolutiva
La buena noticia es que existe un camino que no obliga a elegir entre «aguantar el legacy para siempre» y «quemarlo todo». Se llama modernización evolutiva, y la idea es tan vieja como sensata: cambiar el sistema poco a poco, mientras sigue funcionando.
El patrón clásico para esto es el Strangler Fig —la higuera estranguladora—. El nombre viene de un árbol que crece alrededor de otro hasta reemplazarlo por completo, sin que en ningún momento haya un hueco donde antes había un árbol. Aplicado al software: rodeas el sistema viejo, vas moviendo una capacidad cada vez al nuevo, y apagas la pieza antigua solo cuando la nueva ya la cubre del todo.
Para que esto funcione sin contaminar lo nuevo con los vicios de lo viejo, ayuda una capa anticorrupción: una frontera que traduce entre ambos mundos y evita que los modelos de datos del legacy se filtren hacia el sistema moderno. Es la diferencia entre construir al lado del legacy y construir dentro de él.
¿La ventaja real? Entregas valor desde la primera semana, repartes el riesgo en decenas de pasos pequeños en lugar de concentrarlo en un único big bang, y vas preservando el conocimiento del negocio a medida que lo trasladas, en vez de perderlo de golpe.
Cómo abordarlo en la práctica
El orden importa más que la velocidad. Esto es lo que ha funcionado para mí.
- 1. Mide qué duele de verdad. No reescribas lo que funciona solo porque es feo. Identifica qué partes del sistema concentran los bugs, los retrasos y las quejas. Ahí está tu retorno; el resto puede esperar años sin problema.
- 2. Aísla antes de tocar. Pon una frontera clara entre lo viejo y lo nuevo. Una capa anticorrupción, una API estable, lo que sea. Necesitas poder cambiar una pieza sin que tiemble todo el edificio.
- 3. Empieza por lo de mucho dolor y poco riesgo. La primera migración tiene que ser un éxito visible. Elige algo que importe al negocio pero que, si sale mal, no se lleve por delante la operación. Esa primera victoria te compra la confianza para las difíciles.
- 4. Apaga lo viejo solo cuando lo nuevo lo cubre. El legacy no se borra el día que lanzas el reemplazo. Se borra el día que llevas semanas en producción sin incidentes y nadie lo echa de menos. Mantener las dos versiones un tiempo no es indecisión: es prudencia.
¿Y cuándo sí tiene sentido reescribir?
Sería deshonesto venderte que el rewrite nunca es la respuesta. A veces lo es.
Cuando la tecnología base está realmente muerta —sin soporte, sin gente que la conozca, sin camino de actualización—, parchear es tirar dinero. Cuando el dominio del negocio ha cambiado tanto que el modelo original ya no representa la realidad, arrastrarlo cuesta más que rehacerlo. Y cuando el sistema es pequeño y acotado, reescribir puede ser cuestión de semanas, no de años: ahí el riesgo es asumible.
La clave está en que esa decisión sea una conclusión razonada a partir del coste y el riesgo, no un impulso nacido de la frustración de leer código ajeno. Reescribir porque los números lo justifican es estrategia. Reescribir porque «da pereza entenderlo» es ego con presupuesto.
La pregunta que de verdad importa
Después de quince años haciendo esto, he llegado a una conclusión sencilla: la arquitectura está al servicio del negocio, no al revés.
Modernizar no consiste en perseguir la elegancia técnica ni en tener el stack que mola este año. Consiste en reducir el coste de cambiar mañana sin dejar de entregar hoy. Si una modernización no hace que tu equipo sea más rápido y tu producto más fácil de evolucionar, no es modernización: es redecorar.
Esa es, por cierto, una de las cosas que más valoro cuando acompaño a equipos en Venturest: la decisión correcta casi nunca es la más espectacular. Es la que mantiene el negocio en marcha mientras lo haces más capaz por dentro. Sin lock-in, sin parar la entrega y dejando al equipo más fuerte que antes.
Así que, antes de aprobar ese plan de «reescribámoslo todo», merece la pena hacerse una sola pregunta:
¿Tu equipo está modernizando… o está reescribiendo y rezando?
