Hay un momento en la vida de todo sistema que envejece en el que alguien de la empresa dice, con convicción y cansancio acumulado: "hay que reescribirlo todo".
Es comprensible. El código legacy duele. Los deploys tardan horas. Nadie entiende por qué esa función hace lo que hace. Los tests no existen o mienten. Cada feature nueva es una cirugía con anestesia local.
El problema es que el big bang rewrite — esa idea de tirar todo y empezar desde cero — tiene una tasa de fracaso altísima. Y no por falta de talento técnico.
Por qué falla
1. El sistema viejo sabe cosas que nadie documentó
Ese código que parece sin sentido generalmente tiene sentido. Hay lógica de negocio enterrada en condiciones raras, edge cases que nadie recuerda pero que un cliente en algún lugar del mundo ejecuta todos los meses, integraciones con sistemas externos que tienen comportamientos no documentados.
Cuando reescribís desde cero, perdés ese conocimiento. No lo recuperás del código, porque era ilegible. No lo recuperás de la documentación, porque no existe. Lo descubrís cuando el sistema nuevo falla en producción de formas misteriosas.
2. El target se mueve mientras construís
Un rewrite grande lleva meses. En ese tiempo, el negocio no para. Se agregan features al sistema viejo. Se cambian reglas. Se incorporan nuevos clientes con nuevos requisitos.
Cuando terminás el rewrite, el sistema nuevo ya está desactualizado respecto al viejo. Y el viejo siguió creciendo sin que nadie lo mirara con cariño.
3. La deuda técnica se regenera
Sin los procesos, la cultura y las prácticas que evitan la deuda técnica, el sistema nuevo va a terminar en el mismo estado que el viejo. Solo que más rápido, porque ahora todos están apurados por recuperar el tiempo perdido.
Qué hacer en cambio
La alternativa es la migración incremental. En lugar de reescribir todo, identificás las partes más críticas o más dolorosas y las modernizás una a la vez, sin bajar el sistema.
Las estrategias más efectivas:
Strangler Fig Pattern: construís el sistema nuevo alrededor del viejo. Las nuevas funcionalidades van al sistema nuevo. Las viejas se migran de a una. Con el tiempo, el sistema viejo queda sin funcionalidad y lo apagás.
Feature flags: activás el código nuevo solo para un porcentaje del tráfico. Validás en producción real antes de hacer el corte completo.
Anti-corruption layer: una capa que traduce entre el modelo del sistema viejo y el nuevo, permitiendo que convivan sin que uno contamine al otro.
Cuándo sí tiene sentido reescribir
Hay casos donde el rewrite es legítimo:
- El sistema tiene tan poco tráfico que podés hacer el corte en un fin de semana
- La tecnología es tan obsoleta que no hay forma de ejecutarla en infraestructura moderna
- El scope del rewrite es muy acotado (un módulo, no el sistema completo)
Pero son excepciones, no la regla.
La próxima vez que alguien proponga el big bang rewrite, la pregunta correcta no es "¿con qué tecnología lo reescribimos?". Es: "¿qué parte específica nos está doliendo más y cómo la modernizamos sin tirar todo?".
Es menos épico. Es más efectivo.