Refactorizar o reescribir: la decisión que puede bloquear tu roadmap

El roadmap dice una cosa. La realidad técnica dice otra.

El equipo de producto quiere lanzar tres funcionalidades este trimestre. El equipo de desarrollo dice que, tal como está el sistema, con suerte sacarán una. La conversación siempre acaba en el mismo punto: "es que la base de código no nos deja avanzar".

En ese momento aparecen dos opciones sobre la mesa. Refactorizar: mejorar el sistema actual sin pararlo, limpiando y reestructurando lo que frena. O reescribir: empezar de cero con una arquitectura nueva que resuelva los problemas de raíz.

Las dos suenan razonables. Las dos tienen defensores en el equipo. Y las dos pueden ser la decisión correcta o un error costoso, dependiendo de las circunstancias. El problema es que muchas veces se elige por intuición, por frustración o por presión, en lugar de por análisis.

Este artículo no te va a decir cuál elegir. Te va a dar los criterios para que la decisión sea tuya, pero informada.

Qué significa cada cosa

Conviene empezar por lo básico, porque estos términos se usan de forma ambigua.

Refactorizar es cambiar la estructura interna del código sin cambiar lo que hace. El usuario no nota nada. Lo que cambia es cómo está organizado por dentro: más legible, más mantenible, más fácil de extender. Se trabaja sobre el sistema existente, de forma incremental.

Reescribir es descartar la base de código actual y construir una nueva desde cero que cumpla las mismas funciones (y, normalmente, incorpore mejoras). Es un proyecto en sí mismo, con su propio timeline, presupuesto y equipo.

Entre ambos extremos hay un espectro. No es siempre "una cosa o la otra". Pero entender las diferencias de fondo ayuda a tomar mejores decisiones.

Las señales que abren el debate

Nadie se plantea reescribir un sistema que funciona bien. El debate aparece cuando el dolor es real. Estas son las señales más habituales:

El tiempo de desarrollo se ha multiplicado. Lo que antes tardaba días ahora tarda semanas. No porque el equipo sea peor, sino porque cada cambio requiere entender y sortear capas de complejidad acumulada.

Los bugs son impredecibles. Tocas un módulo y se rompe otro. Las dependencias entre componentes son tan opacas que nadie puede anticipar el efecto de un cambio.

La tecnología de base está obsoleta. El framework ya no tiene soporte, el lenguaje no recibe actualizaciones de seguridad, o la arquitectura impide hacer cosas que el negocio necesita (escalado horizontal, integraciones con APIs modernas, despliegue continuo).

El onboarding es eterno. Los nuevos desarrolladores tardan meses en ser productivos. Hay demasiado conocimiento implícito, poca documentación y muchas "trampas" que solo conocen los veteranos.

El equipo está desmoralizado. Los buenos desarrolladores no quieren trabajar con código que les frustra. Si estás perdiendo talento porque el stack técnico es un lastre, el coste ya no es solo técnico.

Si reconoces varias de estas señales, tienes un problema real. La pregunta es qué solución encaja.

Cuándo refactorizar

Refactorizar es casi siempre la opción más segura. No porque sea la mejor en todos los casos, sino porque el riesgo es mucho menor. Estás trabajando sobre un sistema que ya funciona, con usuarios reales y un historial de comportamiento conocido.

El sistema hace lo que debe, pero cuesta mantenerlo. Si el problema es la calidad interna del código —acoplamiento excesivo, falta de tests, nombres confusos, módulos demasiado grandes— pero la funcionalidad es correcta y la tecnología es viable, refactorizar es la respuesta lógica.

Los problemas están localizados. No todo el sistema es un desastre. Hay zonas que funcionan bien y zonas que no. Puedes atacar las zonas problemáticas sin tocar el resto.

No puedes parar el producto. Si el negocio depende de que el sistema siga funcionando y evolucionando mientras se mejora, una reescritura paralela puede ser inviable. Refactorizar permite mejorar sin detener el desarrollo de producto.

El equipo conoce el sistema. Refactorizar exige entender bien lo que hay. Si el equipo original sigue ahí y conoce las decisiones que se tomaron y por qué, tiene el contexto necesario para mejorar sin romper.

El presupuesto o el plazo son limitados. Refactorizar es incremental. Puedes dedicar un 20% del sprint a mejoras técnicas y obtener resultados graduales. Una reescritura exige una inversión concentrada y un compromiso a largo plazo.

Cuándo reescribir

Reescribir es la opción de mayor riesgo, pero a veces es la única que resuelve el problema de verdad. Hay situaciones en las que mejorar lo que hay es poner parches sobre una estructura que no puede sostenerse.

La tecnología es un callejón sin salida. Si el framework no tiene soporte, el lenguaje está en declive, la base de datos no escala o la arquitectura no permite lo que el negocio necesita, ningún refactoring va a resolverlo. Cambiar los cimientos requiere construir de nuevo.

El coste de mantener supera el coste de construir. Si cada feature nueva cuesta tres veces más de lo que debería y cada arreglo introduce dos bugs nuevos, mantener el sistema existente puede salir más caro que empezar de cero. Pero hay que hacer las cuentas reales, no las optimistas.

Los requisitos han cambiado radicalmente. El sistema se diseñó para un modelo de negocio que ya no existe. Lo que era una web para 100 usuarios ahora necesita servir a 100.000. Lo que era un monolito ahora necesita ser una plataforma con APIs. Si el gap entre lo que el sistema es y lo que necesita ser es demasiado grande, adaptarlo puede ser más costoso que reconstruirlo.

La seguridad es irrecuperable. Si el sistema tiene vulnerabilidades estructurales que no se pueden parchear sin rehacerlo desde la base, la reescritura deja de ser una opción y pasa a ser una necesidad.

Las preguntas que deberías hacerte

Más allá de las señales y los criterios, hay un conjunto de preguntas concretas que te ayudan a tomar la decisión:

¿Cuánto del sistema es rescatable? Si el 70% del código es sólido y el problema está en un 30%, refactoriza. Si el 70% es problemático, la balanza empieza a inclinarse hacia reescribir.

¿Puedes definir con precisión lo que debe hacer el sistema nuevo? Una reescritura sin requisitos claros es una receta para el desastre. Si no puedes especificar qué tiene que hacer el sistema nuevo mejor que el actual, no estás preparado para reescribir.

¿Cuánto tiempo puedes sobrevivir con el sistema actual? Si el sistema aguanta 12-18 meses más con mejoras incrementales, tienes margen para refactorizar. Si está al límite y cualquier pico de tráfico o cambio regulatorio puede romperlo, la urgencia es otra.

¿Qué pasa con el producto mientras tanto? Una reescritura puede tardar 12, 18 o 24 meses. Durante ese tiempo, el producto actual se congela o avanza a velocidad mínima. ¿Tu negocio puede permitírselo? ¿Tus competidores van a esperar?

¿Tienes el equipo para hacerlo? Una reescritura necesita desarrolladores experimentados que entiendan tanto el sistema actual como la arquitectura objetivo. Si no tienes ese equipo, externalizar una reescritura completa es una apuesta de muy alto riesgo.

La tercera vía: el strangler fig

Hay una opción que muchas veces se pasa por alto y que combina lo mejor de ambos enfoques: la migración progresiva, también conocida como strangler fig pattern.

El nombre viene de la higuera estranguladora, una planta que crece alrededor de un árbol existente hasta que lo reemplaza por completo. En software, la idea es la misma: construyes las nuevas piezas alrededor del sistema actual, las vas conectando gradualmente y, con el tiempo, el sistema nuevo reemplaza al antiguo sin que haya habido un "gran apagón".

En la práctica, funciona así: identificas un módulo o funcionalidad del sistema actual, lo reconstruyes con la tecnología nueva como un servicio independiente, y rediriges el tráfico o las llamadas hacia el nuevo componente. El sistema antiguo sigue funcionando para todo lo demás. Repites el proceso módulo a módulo.

Las ventajas son claras. No paras el producto. Cada nuevo componente se puede probar y desplegar de forma independiente. Si algo falla, solo afecta a la parte migrada, no a todo el sistema. Y el equipo no tiene que mantener dos sistemas completos en paralelo durante meses.

No es una bala de plata. Requiere una buena definición de las fronteras entre módulos, y funciona mejor en sistemas con cierta modularidad (o donde se puede introducir una capa de routing). Pero para muchos proyectos, es la opción más pragmática.

Los errores más comunes al decidir

Decidir por frustración. "Estoy harto de este código, vamos a reescribirlo" no es un análisis: es una emoción. Las reescrituras motivadas por la frustración suelen subestimar la complejidad del sistema actual y sobreestimar lo fácil que será el nuevo.

Subestimar lo que el código actual "sabe". Cada línea de código en producción contiene decisiones, correcciones de bugs y casos límite que se descubrieron con el tiempo. Reescribir significa redescubrir todo eso. Si no lo tienes en cuenta, el sistema nuevo repetirá los mismos errores.

No involucrar al negocio. La decisión de refactorizar o reescribir no es solo técnica. Tiene implicaciones en plazos, presupuesto, funcionalidades y riesgo. Si el equipo técnico decide solo, puede elegir la opción técnicamente elegante pero empresarialmente inviable.

Comparar el sistema actual con el sistema nuevo ideal. Es fácil que la reescritura gane cuando la comparas con la versión perfecta que tienes en la cabeza. Pero esa versión no existe. Compara el sistema actual con lo que realistamente vas a poder construir con los recursos y plazos que tienes.

No definir criterios de éxito antes de empezar. ¿Cómo sabrás que la refactorización ha funcionado? ¿Cómo medirás que la reescritura ha cumplido su objetivo? Sin métricas concretas —tiempo medio de desarrollo de una feature, número de incidencias por mes, tiempo de onboarding— no puedes evaluar si la decisión fue correcta.

Un framework para decidir

Si necesitas una guía rápida, estas son las preguntas en orden:

¿La tecnología de base tiene futuro? Si no, reescribe (o migra progresivamente). Si sí, sigue.

¿Los problemas están localizados o son sistémicos? Si están localizados, refactoriza. Si son sistémicos, sigue.

¿Puedes definir con claridad los requisitos del sistema nuevo? Si no, no estás preparado para reescribir. Refactoriza mientras clarificas. Si sí, sigue.

¿Tienes equipo, presupuesto y tiempo para una reescritura? Si no, refactoriza. Si sí, valora el strangler fig antes del big bang.

No es un algoritmo perfecto, pero obliga a responder preguntas incómodas antes de tomar la decisión. Y eso, en sí mismo, ya mejora el resultado.

Lo que importa de verdad

La peor decisión no es elegir refactorizar cuando había que reescribir, ni reescribir cuando bastaba con refactorizar. La peor decisión es no decidir. Seguir arrastrando un sistema que frena al equipo, que frustra al negocio y que acumula riesgo cada día que pasa.

Si tu roadmap lleva meses chocando con la realidad técnica, el problema no va a resolverse solo. Analiza, decide y actúa. Y si no tienes claro qué opción encaja, busca a alguien que haya pasado por esto antes. La experiencia de quien ha visto las dos opciones funcionar (y fallar) vale más que cualquier framework teórico.